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