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