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 >
