Hi, We have two kinds of causes which can emit warnings: 1. wrong using of plugin by user like use deprecated or unexisting parameters, using deprecated goals 2. wrong implementation in plugin, eg scope, EOL components
First group should be displayed - because the end user can fix their own build Second should be mentioned in brief mode. So I think we should split notification for such two groups and figure out - discuss how to best inform each group separately. pt., 19 maj 2023 o 21:32 Romain Manni-Bucau <rmannibu...@gmail.com> napisał(a): > +1 to make NONE the default, know it defeats the purpose but this feature > makes end user builds nasty whereas it should help them. > > I would also be +1 to make it a help:check-state goal rather than having it > in maven core where it is quite pointless IMHO as explained in earlier > threads. > > Le ven. 19 mai 2023 à 21:17, Henning Schmiedehausen < > henn...@schmiedehausen.org> a écrit : > > > Hi Gary, > > > > Seems we both work in similar places. :-) Looking at > > > > > https://github.com/apache/maven/commit/11d97e64e7e3fbed23d8e98abdd8c015a957ee82 > > , > > it seems that 3.9.3 (whenever that comes) will improve things; the > default > > logging is still not great but at least I can add > > `<maven.plugin.validation>NONE</maven.plugin.validation>` to all my > > projects get back to the pre-3.9.x state. @michaelo might like that as > > well. > > > > @tamas I would have preferred if we did not add a "NONE" setting but made > > the "DEFAULT" value having no logging and replaced what is "DEFAULT" in > > 3.9.2 with "SUMMARY" or "NORMAL" or something else. That way, the default > > state would be the same as it was with maven 3.8.x (which is IMHO the > right > > thing to call "default") and everyone who wants to actually log warnings > > can turn it on. > > > > Adding the property above to my poms is a stop-gap, as it emits a warning > > on pre-3.9.3 maven versions, something that I can not fix because older > > versions of the build tool are "out there". I could put the property > under > > a profile but at that point it feels like fighting the tool. > > > > -h > > > > (pro-tip: Never call the value for a default setting "default". "default" > > is a state, not a value. If you want to change the "default" state, you > are > > now stuck with a value called "default") > > > > > > > > On Fri, May 19, 2023 at 11:47 AM Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > > > From this user's POV, I feel these warning force me to spin my wheels: > > If I > > > have old plugins I can update their versions, and then I still get the > > > warnings, none of which I can do anything about. I can do something > about > > > compiler warnings, I can do nothing about these. > > > > > > I am left to explain up and down the food chain with hand handwaving > why > > > these warnings are "ok" :-( > > > > > > Gary > > > > > > > > > On Fri, May 19, 2023, 14:15 Henning Schmiedehausen < > > > henn...@schmiedehausen.org> wrote: > > > > > > > Hi Tamas, > > > > > > > > Thanks for the quick response. > > > > > > > > On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák <ta...@cservenak.net > > > > > > wrote: > > > > > > > > > Howdy, > > > > > > > > > > So, have a small local change, probably to go with 3.9.3. > > > > > > > > > > > > > [...] > > > > > > > > > > > > > [WARNING] * org.basepom.maven:inline-maven-plugin:1.0.1 > > > > > [WARNING] Declared at location(s): > > > > > [WARNING] * org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) @ > > > line > > > > > 145 > > > > > [WARNING] Used in module(s): > > > > > [WARNING] * org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) > > > > > [WARNING] Plugin issue(s): > > > > > [WARNING] * Plugin descriptor should not contain these Maven > > > > artifacts: > > > > > [org.apache.maven:maven-artifact:3.8.4, > > > > > org.apache.maven:maven-settings-builder:3.8.4, > > > > > org.apache.maven:maven-repository-metadata:3.8.4, > > > > > org.apache.maven:maven-builder-support:3.8.4, > > > > > org.apache.maven:maven-core:3.8.4, > > > > > org.apache.maven:maven-resolver-provider:3.8.4, > > > > > org.apache.maven:maven-settings:3.8.4, > > > > > org.apache.maven:maven-plugin-api:3.8.4, > > > > > org.apache.maven:maven-model-builder:3.8.4, > > > > > org.apache.maven:maven-model:3.8.4] > > > > > > > > > > > > > This has *zero* meaning to the person running the build. And it still > > > does > > > > not help the plugin author either. Because they (I) used the maven > tool > > > > chain that was current at the point in time the plugin was created. > > There > > > > is still no actionable advice in here and there is no link to any > > > > documentation that tells a plugin author what the root cause is and > > what > > > to > > > > do. Developers can now either do the "update everything and pray", an > > > > approach that worked exceedingly well with maven dependencies (look > at > > > all > > > > the incompatibilities with the 4.0.0-M<x> components) or turn around > to > > > the > > > > maven mailing list asking "what should I do". > > > > > > > > You need to write documentation that helps your users. All the error > > > > messages and warnings and "this is wrong, fix it" messages to users > do > > > not > > > > help. > > > > > > > > This passive-aggressive attempt to surface problems in an obscure way > > to > > > > the end user and hope that "they file bugs with the plugin authors" > is > > a > > > > terrible way to instigate change. > > > > > > > > I understand that there is limited developer time on Maven and this > > looks > > > > tempting as the "simplest path" but all you have accomplished is > reduce > > > > trust. "maven suddenly reports problems that were not there before. > > Were > > > > those always there? Are my builds still good? Do my older projects > > still > > > > build?" > > > > > > > > Surfacing non-actionable warnings or errors to a non-audience is a > > no-no > > > > for any user experience; this is UX 101. > > > > > > > > For Jdbi, I still get complaints > > > > about org.apache.maven.plugins:maven-pmd-plugin, > > > > org.apache.maven.plugins:maven-javadoc-plugin, > > > > org.apache.maven.plugins:maven-source-plugin, > > > > org.apache.maven.plugins:maven-dependency-plugin. > > > > So even the official maven plugins have not gotten this right. Of > > course > > > > you can say "time heals all wounds". That is not true, because there > is > > > > attrition by people switching tools. Heck, the ASF is now running a > > > gradle > > > > enterprise server. > > > > > > > > You need to turn all of these warnings *OFF* and document the > existence > > > of > > > > the switch *and* give developer documentation what you expect plugin > > > users > > > > *to do*. And then evangelize that. That will get your allies (which > are > > > the > > > > plugin authors that will *want* to fix the problems) to help you. > Not > > > > throw out another release with slightly tweaked warnings. > > > > > > > > Calling "maven 3.9 is about the journey to 4.0" is ridiculous. Maven > > 3.9 > > > is > > > > a, by definition, fully backwards compatible release of Apache Maven > > 3.x. > > > > If you need a journey, then release Maven 4.0.0 as that stepping > stone > > > and > > > > then 5.0 as a backwards incompatible version. Maven 4 has been in > > > > development for many years and developer uptake will take a long > time, > > > > especially if all old builds break left and right. You may even end > up > > > > having to call it "mvn4" and not "mvn" to not break build scripts in > > > > countless organizations. > > > > > > > > -h > > > > > > > > > > > > > > > > > > > > > > > -- Sławomir Jaranowski
