I put https://github.com/apache/maven/pull/1116 together which does exactly that. It is literally three lines of code.
-h On Fri, May 19, 2023 at 12:17 PM Henning Schmiedehausen < henn...@schmiedehausen.org> wrote: > 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 >> > >> > >> > > >> > >> >
