+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 > > > > > > > > > > > > > > > >
