Thank you for speaking up. I would encourage others that feel the same way
to speak up as well. I do not believe that the "we ram this through and
hope that at some point all plugins are updated so the warnings die down"
is a viable approach.
This is what I wrote on the PR ("you/your" is @tamas here): *"I very much
disagree with your "my way or the highway" approach. There is a lot of
criticism with the approach to "the purpose". Of course, you can just ram
your approach through and hope for the best. It will not work, as the
changes will break older builds that people do not update and you cause
continuing pain for developers. People will be stuck on 3.9 forever because
"it is the last version that supports that unmaintained foo plugin that I
need for my build and can not move off" and grind their teeth. The answer
will be "we move off maven", not "we fix that plugin"."*
Not going where the users are or actively snubbing your users is a good way
to lose users. 3.9.x so far is a case study on focusing on the maven
developers own needs and snubbing the maven users.
-h
On Fri, May 19, 2023 at 12:33 PM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> +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
> > > >
> > > >
> > > > >
> > > >
> > >
> >
>
