You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Henning Schmiedehausen <he...@schmiedehausen.org> on 2023/05/13 19:22:20 UTC
Some thoughts about the maven parameter deprecation messages
Hi,
[I wanted to write about this for a while]
Maven has recently (3.9.x) started to log warning messages like this:
*[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
use of ArtifactRepository type. If you need access to local repository,
switch to '${repositorySystemSession}' expression and get LRM from it
instead.*
I understand that this is an attempt to get plugin developers to replace
APIs that are considered deprecated.
Here is my take on this attempt:
- The messages are shown to end users. *The end user is not the audience.*
Plugin authors are. Most end users can not do anything about these errors
but "upgrade the plugin version and hope for the best" or "file a report
with the plugin authors (see
https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 or
https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"
- The messages are logged at "WARNING" level. So builds break for some
users. *This is a bad user experience.* Best case scenario: Users work
around (upgrade maven, downgrade maven, upgrade plugins, change build
system setup). Worst case scenario: Use a different build tool so you just
lost an user. Less users means fewer contributions, means less traction.
That is how projects die.
- *People need to build older code bases that use older versions of plugins*.
They want to use "the `mvn` command" which may be installed by their OS or
some packaging tool. They either experience a plethora of warnings "that
were not there before" or need to install older versions of maven manually
which is hard/impossible for many users. Spending time on "upgrading the
build system", especially for larger projects is not an option (either
skill-wise or willingness to spend time on a project that someone wants to
evaluate or try out).
- *The messages are not actionable*. There are official plugins (pmd is the
latest example) whose current version logs these errors. *There is no
workaround for end users.*
- *There is not a clear path for plugin authors on how to fix this.*
Googling for "maven localRepository deprecation" reports
https://issues.apache.org/jira/browse/MNG-7706 as the fifth or sixth link
(below the fold) which describes why this is reported but no clear recipe
like "replace this dependency with this dependency. Use this injection."
There are cryptic comments like the one on
https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 which points
at https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads "*Recent
Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0
branch as well. With the upcoming major version this will be implicitly
solved.*". Even if someone *wants* to contribute possible fixes, there is
simply not enough information. And naively replacing the dependency leads
to other errors (and probably stops working in older versions of maven).
To summarize: From my PoV, *it is a bad decision to display deprecation
messages that are intended for plugin authors to end users*. If the goal is
to get plugin authors to change their code, this is the wrong way. It feels
passive aggressive to me ("get end users to report bugs to plugins, so the
plugin authors are compelled to fix this").
Here are some suggestions:
- the vast majority of builds have been designed for maven 3.x.x and they
will keep using plugins that work with maven 3.x.x. So 3.x.x should not
display warnings in the first place.
- Removing these deprecated APIs is not an option for the 3.x.x cycle, so
why display warnings about it? Introducing this in 3.8 -> 3.9 is wrong as
there is an expectation with users that "upgrading a minor version should
just work" (Backwards compatibility).
- make it clear when things will stop working. Is that maven 4.x.x? Great.
Having 4.0.0 show these warnings may be acceptable (as this is a new major
version). Document that 4.0.0 will support them with warnings and 4.1.0
will no longer support them.
- show these warnings in the developer tooling. Every maven developer uses
the maven-plugin-plugin. Or plexus-component-metadata. Having those tools
showing warnings (or errors) makes sense, because the audience are plugin
developers and they can actually fix the problems.
- Maven could have a "lint" or "-Wall" mode under a switch. If that switch
is on, show these warnings. Otherwise, don't. The switch needs to be
documented clearly. The argument "no one will use that" does not count. If
it is documented, plugin developers will use it to find this type of
problem. Build engineers will use it to find incompatibilities.
- At the very minimum, ensure that all "official" maven plugins (the ones
on https://maven.apache.org/plugins/index.html) are all updated before
enabling this type of warning. At the very least, end users then *can* get
rid of them by upgrading. The argument "This is a lot of work and we are
only a few people that no one thanks for our hard work" is not an argument
here. If this is a problem for code that is maintained as official plugins,
then these warnings can not be added before all the plugins are updated.
- Make it possible to help and provide patches. I know of many people that
would chip in and help if there were a clear, actionable path to upgrade a
plugin. Currently there is not and it would be good to create that.
Feel free to agree, disagree, ignore. I am maintaining a set of base poms
for starting and maintaining maven projects over at https://basepom.org and
this is a pain that I go through every day when choosing to upgrade or use
plugins. Apache Maven makes this harder than it should be.
-h
Re: Some thoughts about the maven parameter deprecation messages
Posted by Olivier Lamy <ol...@apache.org>.
Yes I tend to agree the user experience is really confusing currently.
Just use mvn archetype:generate with the default project and warnings
are generated.
[WARNING] Plugin validation issues were detected in 2 plugin(s)
[WARNING] * org.apache.maven.plugins:maven-site-plugin:3.12.1
[WARNING] * org.apache.maven.plugins:maven-archetype-plugin:3.2.1
then build (e.g mvn verify) the default generated project and there
are plenty of warnings:
[WARNING] Plugin validation issues were detected in 4 plugin(s)
[WARNING] * org.apache.maven.plugins:maven-compiler-plugin:3.8.0
[WARNING] * org.apache.maven.plugins:maven-jar-plugin:3.0.2
[WARNING] * org.apache.maven.plugins:maven-resources-plugin:3.0.2
[WARNING] * org.apache.maven.plugins:maven-surefire-plugin:2.22.1
Same applies when you use an empty pom (e.g default binding) this
generates warning users cannot do anything about.
As we all know it takes time to update all the plugins/tooling (and
thanks for all the job done here) but as we are not ready here maybe
we should not display those warnings until at least all our
plugins/tools have been updated?
or only a single line which can be expanded when passing a parameter.
On Sun, 14 May 2023 at 05:22, Henning Schmiedehausen
<he...@schmiedehausen.org> wrote:
>
> Hi,
>
> [I wanted to write about this for a while]
>
> Maven has recently (3.9.x) started to log warning messages like this:
>
> *[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it
> instead.*
>
> I understand that this is an attempt to get plugin developers to replace
> APIs that are considered deprecated.
>
> Here is my take on this attempt:
>
> - The messages are shown to end users. *The end user is not the audience.*
> Plugin authors are. Most end users can not do anything about these errors
> but "upgrade the plugin version and hope for the best" or "file a report
> with the plugin authors (see
> https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 or
> https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"
>
> - The messages are logged at "WARNING" level. So builds break for some
> users. *This is a bad user experience.* Best case scenario: Users work
> around (upgrade maven, downgrade maven, upgrade plugins, change build
> system setup). Worst case scenario: Use a different build tool so you just
> lost an user. Less users means fewer contributions, means less traction.
> That is how projects die.
>
> - *People need to build older code bases that use older versions of plugins*.
> They want to use "the `mvn` command" which may be installed by their OS or
> some packaging tool. They either experience a plethora of warnings "that
> were not there before" or need to install older versions of maven manually
> which is hard/impossible for many users. Spending time on "upgrading the
> build system", especially for larger projects is not an option (either
> skill-wise or willingness to spend time on a project that someone wants to
> evaluate or try out).
>
> - *The messages are not actionable*. There are official plugins (pmd is the
> latest example) whose current version logs these errors. *There is no
> workaround for end users.*
>
> - *There is not a clear path for plugin authors on how to fix this.*
> Googling for "maven localRepository deprecation" reports
> https://issues.apache.org/jira/browse/MNG-7706 as the fifth or sixth link
> (below the fold) which describes why this is reported but no clear recipe
> like "replace this dependency with this dependency. Use this injection."
> There are cryptic comments like the one on
> https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 which points
> at https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads "*Recent
> Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0
> branch as well. With the upcoming major version this will be implicitly
> solved.*". Even if someone *wants* to contribute possible fixes, there is
> simply not enough information. And naively replacing the dependency leads
> to other errors (and probably stops working in older versions of maven).
>
>
> To summarize: From my PoV, *it is a bad decision to display deprecation
> messages that are intended for plugin authors to end users*. If the goal is
> to get plugin authors to change their code, this is the wrong way. It feels
> passive aggressive to me ("get end users to report bugs to plugins, so the
> plugin authors are compelled to fix this").
>
> Here are some suggestions:
>
> - the vast majority of builds have been designed for maven 3.x.x and they
> will keep using plugins that work with maven 3.x.x. So 3.x.x should not
> display warnings in the first place.
>
> - Removing these deprecated APIs is not an option for the 3.x.x cycle, so
> why display warnings about it? Introducing this in 3.8 -> 3.9 is wrong as
> there is an expectation with users that "upgrading a minor version should
> just work" (Backwards compatibility).
>
> - make it clear when things will stop working. Is that maven 4.x.x? Great.
> Having 4.0.0 show these warnings may be acceptable (as this is a new major
> version). Document that 4.0.0 will support them with warnings and 4.1.0
> will no longer support them.
>
> - show these warnings in the developer tooling. Every maven developer uses
> the maven-plugin-plugin. Or plexus-component-metadata. Having those tools
> showing warnings (or errors) makes sense, because the audience are plugin
> developers and they can actually fix the problems.
>
> - Maven could have a "lint" or "-Wall" mode under a switch. If that switch
> is on, show these warnings. Otherwise, don't. The switch needs to be
> documented clearly. The argument "no one will use that" does not count. If
> it is documented, plugin developers will use it to find this type of
> problem. Build engineers will use it to find incompatibilities.
>
> - At the very minimum, ensure that all "official" maven plugins (the ones
> on https://maven.apache.org/plugins/index.html) are all updated before
> enabling this type of warning. At the very least, end users then *can* get
> rid of them by upgrading. The argument "This is a lot of work and we are
> only a few people that no one thanks for our hard work" is not an argument
> here. If this is a problem for code that is maintained as official plugins,
> then these warnings can not be added before all the plugins are updated.
>
> - Make it possible to help and provide patches. I know of many people that
> would chip in and help if there were a clear, actionable path to upgrade a
> plugin. Currently there is not and it would be good to create that.
>
>
> Feel free to agree, disagree, ignore. I am maintaining a set of base poms
> for starting and maintaining maven projects over at https://basepom.org and
> this is a pain that I go through every day when choosing to upgrade or use
> plugins. Apache Maven makes this harder than it should be.
>
> -h
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts about the maven parameter deprecation messages
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 13 mai 2023 à 22:13, Jeremy Landis <je...@hotmail.com> a
écrit :
> I think 'end users' are the ones that need to report to plugin owners.
> Plugin authors are highly unlikely to even know about this issue unless
> working their plugins. The latest maven 3.9.2 though IMO did this wrong.
> When the issues pop, it makes end users open tickets at very least.
>
Part of them will, most will not and ultimately you still get a warning you
cant fix, cant be right.
We can work on our build tooling to download signatures from the net and
check if plugin code will work with last releases, then a daily build will
warn plugin maintainer if it exists....no tech reason to bother all
downstream users who cant do anything anyway.
> However, maven 3.9.2 is problematic with this. BRIEF is effectively
> useless. Just says X number of plugins have issues with zero info and
> tells user to change behavior to figure that out. Maybe that is fine for
> end users that won't cause them to report anything.
> DEFAULT is useless, tells me the plugins but doesn't tell me the issue.
> Again for end users they won't report a thing. So we are left with VERBOSE
> which is far too noisy for end users and incredibly hard to read.
>
> Regardless all are a regression from maven 3.9.1 which was at least clear
> what issues existed in what I'd consider the default even though moved to
> the end which is better as easy to figure out. The data as in 3.9.1 got
> attention. It got end users to upgrade plugins, report issues. It got
> supporters of end users to start getting engaged more on OSS plugins
> outside of maven. It got my attention to act on many I support and even
> picking some up that are dead ends in current ownership.
>
> Now, at least from my perspective, our forced process at work set this up
> to VERBOSE for 3.9.2 to force users to upgrade to our supported super pom
> revisions. Even then, VERBOSE is incredibly hard to read, super noisy. It
> needs rewritten so its clear from one plugin to the next. A single * for
> each plugin doesn't clearly separate. There further needs to be some other
> state that is more akin to what 3.9.1 was doing at the end in same way. A
> 4th option would be helpful. I don't want my users seeing VERBOSE but it's
> the only acceptable usage IMO for 3.9.2. I do want them seeing what 3.9.1
> provided. In many cases, they only need to upgrade so they are the ones to
> see that. At least from maven camp most plugins have been fixed. But
> again this stuff was probably too premature when maven didn't deal with
> many plugins or release many yet (javadocs, source, others...). Probably
> should have released patches before blasting world with issues that were
> not fixed. Its hard to say what all OSS ones exist that are not known so
> those are expected. Its just really discerning when it says some maven
> plugin supported by maven isn't even compliant.
>
> That all said, maybe IMO I'm right audience for addressing at my firm
> considering I support a super pom that contains these and I want the
> downstream users to be on the latest super pom. For the remainder of
> issues, I'm either watching very closely for releases or looking to get
> engaged with various plugins that have failed to do prior updates
> (jacoco/git commit for example). But ultimately I need my end users
> reporting issues. Even with a super pom, not everything executes there and
> the vast ecosystem requires that I get feedback from downstream users.
> Even noisy or not, its expected short lived (hopefully).
>
> -----Original Message-----
> From: Romain Manni-Bucau <rm...@gmail.com>
> Sent: Saturday, May 13, 2023 3:54 PM
> To: Maven Developers List <de...@maven.apache.org>
> Subject: Re: Some thoughts about the maven parameter deprecation messages
>
> +1 very close to what I expressed on slack.
>
> Think end user should also be able to see these warning to select a plugi
> or evaluate a migration but at request -> new help plugin goal IMHO.
>
> Le sam. 13 mai 2023 à 21:22, Henning Schmiedehausen <
> henning@schmiedehausen.org> a écrit :
>
> > Hi,
> >
> > [I wanted to write about this for a while]
> >
> > Maven has recently (3.9.x) started to log warning messages like this:
> >
> > *[WARNING] Parameter 'localRepository' is deprecated core expression;
> > Avoid use of ArtifactRepository type. If you need access to local
> > repository, switch to '${repositorySystemSession}' expression and get
> > LRM from it
> > instead.*
> >
> > I understand that this is an attempt to get plugin developers to
> > replace APIs that are considered deprecated.
> >
> > Here is my take on this attempt:
> >
> > - The messages are shown to end users. *The end user is not the
> > audience.* Plugin authors are. Most end users can not do anything
> > about these errors but "upgrade the plugin version and hope for the
> > best" or "file a report with the plugin authors (see
> > https://issue/
> > s.apache.org%2Fjira%2Fprojects%2FMPMD%2Fissues%2FMPMD-368&data=05%7C01%7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EdP4C3EpOQyPGV3EY%2FOr1MGQACw%2FQQN6gbNSG8ZdBGI%3D&reserved=0
> or https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"
> >
> > - The messages are logged at "WARNING" level. So builds break for some
> > users. *This is a bad user experience.* Best case scenario: Users work
> > around (upgrade maven, downgrade maven, upgrade plugins, change build
> > system setup). Worst case scenario: Use a different build tool so you
> > just lost an user. Less users means fewer contributions, means less
> traction.
> > That is how projects die.
> >
> > - *People need to build older code bases that use older versions of
> > plugins*.
> > They want to use "the `mvn` command" which may be installed by their
> > OS or some packaging tool. They either experience a plethora of
> > warnings "that were not there before" or need to install older
> > versions of maven manually which is hard/impossible for many users.
> > Spending time on "upgrading the build system", especially for larger
> > projects is not an option (either skill-wise or willingness to spend
> > time on a project that someone wants to evaluate or try out).
> >
> > - *The messages are not actionable*. There are official plugins (pmd
> > is the latest example) whose current version logs these errors. *There
> > is no workaround for end users.*
> >
> > - *There is not a clear path for plugin authors on how to fix this.*
> > Googling for "maven localRepository deprecation" reports
> > https://issue/
> > s.apache.org%2Fjira%2Fbrowse%2FMNG-7706&data=05%7C01%7C%7Cb90c7f91bae7
> >
> 44f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Yr2KZEyhff0YuluE%2FKA7pw55hUTFb1if%2Byqg6Nk3OVc%3D&reserved=0
> as the fifth or sixth link (below the fold) which describes why this is
> reported but no clear recipe like "replace this dependency with this
> dependency. Use this injection."
> > There are cryptic comments like the one on
> > https://issue/
> > s.apache.org%2Fjira%2Fprojects%2FMPMD%2Fissues%2FMPMD-368&data=05%7C01
> > %7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaa
> > aaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> > jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> > sdata=EdP4C3EpOQyPGV3EY%2FOr1MGQACw%2FQQN6gbNSG8ZdBGI%3D&reserved=0
> > which points at
> > https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads
> "*Recent Maven Reporting Impl is local localRepository-free. See my
> doxia-2.0.0 branch as well. With the upcoming major version this will be
> implicitly solved.*". Even if someone *wants* to contribute possible fixes,
> there is simply not enough information. And naively replacing the
> dependency leads to other errors (and probably stops working in older
> versions of maven).
> >
> >
> > To summarize: From my PoV, *it is a bad decision to display
> > deprecation messages that are intended for plugin authors to end
> > users*. If the goal is to get plugin authors to change their code,
> > this is the wrong way. It feels passive aggressive to me ("get end
> > users to report bugs to plugins, so the plugin authors are compelled to
> fix this").
> >
> > Here are some suggestions:
> >
> > - the vast majority of builds have been designed for maven 3.x.x and
> > they will keep using plugins that work with maven 3.x.x. So 3.x.x
> > should not display warnings in the first place.
> >
> > - Removing these deprecated APIs is not an option for the 3.x.x cycle,
> > so why display warnings about it? Introducing this in 3.8 -> 3.9 is
> > wrong as there is an expectation with users that "upgrading a minor
> > version should just work" (Backwards compatibility).
> >
> > - make it clear when things will stop working. Is that maven 4.x.x?
> Great.
> > Having 4.0.0 show these warnings may be acceptable (as this is a new
> > major version). Document that 4.0.0 will support them with warnings
> > and 4.1.0 will no longer support them.
> >
> > - show these warnings in the developer tooling. Every maven developer
> > uses the maven-plugin-plugin. Or plexus-component-metadata. Having
> > those tools showing warnings (or errors) makes sense, because the
> > audience are plugin developers and they can actually fix the problems.
> >
> > - Maven could have a "lint" or "-Wall" mode under a switch. If that
> > switch is on, show these warnings. Otherwise, don't. The switch needs
> > to be documented clearly. The argument "no one will use that" does not
> > count. If it is documented, plugin developers will use it to find this
> > type of problem. Build engineers will use it to find incompatibilities.
> >
> > - At the very minimum, ensure that all "official" maven plugins (the
> > ones on
> > https://maven/
> > .apache.org%2Fplugins%2Findex.html&data=05%7C01%7C%7Cb90c7f91bae744f71
> > b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044
> > 709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> >
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R4MgBcFJqomEFBH%2FzV07AjRJ2EMBiRmykeNUMGJFL6c%3D&reserved=0)
> are all updated before enabling this type of warning. At the very least,
> end users then *can* get rid of them by upgrading. The argument "This is a
> lot of work and we are only a few people that no one thanks for our hard
> work" is not an argument here. If this is a problem for code that is
> maintained as official plugins, then these warnings can not be added before
> all the plugins are updated.
> >
> > - Make it possible to help and provide patches. I know of many people
> > that would chip in and help if there were a clear, actionable path to
> > upgrade a plugin. Currently there is not and it would be good to create
> that.
> >
> >
> > Feel free to agree, disagree, ignore. I am maintaining a set of base
> > poms for starting and maintaining maven projects over at
> > https://basep/
> > om.org%2F&data=05%7C01%7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7
> > fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWF
> > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> > n0%3D%7C3000%7C%7C%7C&sdata=GdLjKtwepC%2FKFIfXJYibcCgu0KNr7FUN4QYBDcOy
> > 3cA%3D&reserved=0
> > and
> > this is a pain that I go through every day when choosing to upgrade or
> > use plugins. Apache Maven makes this harder than it should be.
> >
> > -h
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: Some thoughts about the maven parameter deprecation messages
Posted by Jeremy Landis <je...@hotmail.com>.
I think 'end users' are the ones that need to report to plugin owners. Plugin authors are highly unlikely to even know about this issue unless working their plugins. The latest maven 3.9.2 though IMO did this wrong. When the issues pop, it makes end users open tickets at very least.
However, maven 3.9.2 is problematic with this. BRIEF is effectively useless. Just says X number of plugins have issues with zero info and tells user to change behavior to figure that out. Maybe that is fine for end users that won't cause them to report anything.
DEFAULT is useless, tells me the plugins but doesn't tell me the issue. Again for end users they won't report a thing. So we are left with VERBOSE which is far too noisy for end users and incredibly hard to read.
Regardless all are a regression from maven 3.9.1 which was at least clear what issues existed in what I'd consider the default even though moved to the end which is better as easy to figure out. The data as in 3.9.1 got attention. It got end users to upgrade plugins, report issues. It got supporters of end users to start getting engaged more on OSS plugins outside of maven. It got my attention to act on many I support and even picking some up that are dead ends in current ownership.
Now, at least from my perspective, our forced process at work set this up to VERBOSE for 3.9.2 to force users to upgrade to our supported super pom revisions. Even then, VERBOSE is incredibly hard to read, super noisy. It needs rewritten so its clear from one plugin to the next. A single * for each plugin doesn't clearly separate. There further needs to be some other state that is more akin to what 3.9.1 was doing at the end in same way. A 4th option would be helpful. I don't want my users seeing VERBOSE but it's the only acceptable usage IMO for 3.9.2. I do want them seeing what 3.9.1 provided. In many cases, they only need to upgrade so they are the ones to see that. At least from maven camp most plugins have been fixed. But again this stuff was probably too premature when maven didn't deal with many plugins or release many yet (javadocs, source, others...). Probably should have released patches before blasting world with issues that were not fixed. Its hard to say what all OSS ones exist that are not known so those are expected. Its just really discerning when it says some maven plugin supported by maven isn't even compliant.
That all said, maybe IMO I'm right audience for addressing at my firm considering I support a super pom that contains these and I want the downstream users to be on the latest super pom. For the remainder of issues, I'm either watching very closely for releases or looking to get engaged with various plugins that have failed to do prior updates (jacoco/git commit for example). But ultimately I need my end users reporting issues. Even with a super pom, not everything executes there and the vast ecosystem requires that I get feedback from downstream users. Even noisy or not, its expected short lived (hopefully).
-----Original Message-----
From: Romain Manni-Bucau <rm...@gmail.com>
Sent: Saturday, May 13, 2023 3:54 PM
To: Maven Developers List <de...@maven.apache.org>
Subject: Re: Some thoughts about the maven parameter deprecation messages
+1 very close to what I expressed on slack.
Think end user should also be able to see these warning to select a plugi or evaluate a migration but at request -> new help plugin goal IMHO.
Le sam. 13 mai 2023 à 21:22, Henning Schmiedehausen < henning@schmiedehausen.org> a écrit :
> Hi,
>
> [I wanted to write about this for a while]
>
> Maven has recently (3.9.x) started to log warning messages like this:
>
> *[WARNING] Parameter 'localRepository' is deprecated core expression;
> Avoid use of ArtifactRepository type. If you need access to local
> repository, switch to '${repositorySystemSession}' expression and get
> LRM from it
> instead.*
>
> I understand that this is an attempt to get plugin developers to
> replace APIs that are considered deprecated.
>
> Here is my take on this attempt:
>
> - The messages are shown to end users. *The end user is not the
> audience.* Plugin authors are. Most end users can not do anything
> about these errors but "upgrade the plugin version and hope for the
> best" or "file a report with the plugin authors (see
> https://issue/
> s.apache.org%2Fjira%2Fprojects%2FMPMD%2Fissues%2FMPMD-368&data=05%7C01%7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EdP4C3EpOQyPGV3EY%2FOr1MGQACw%2FQQN6gbNSG8ZdBGI%3D&reserved=0 or https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"
>
> - The messages are logged at "WARNING" level. So builds break for some
> users. *This is a bad user experience.* Best case scenario: Users work
> around (upgrade maven, downgrade maven, upgrade plugins, change build
> system setup). Worst case scenario: Use a different build tool so you
> just lost an user. Less users means fewer contributions, means less traction.
> That is how projects die.
>
> - *People need to build older code bases that use older versions of
> plugins*.
> They want to use "the `mvn` command" which may be installed by their
> OS or some packaging tool. They either experience a plethora of
> warnings "that were not there before" or need to install older
> versions of maven manually which is hard/impossible for many users.
> Spending time on "upgrading the build system", especially for larger
> projects is not an option (either skill-wise or willingness to spend
> time on a project that someone wants to evaluate or try out).
>
> - *The messages are not actionable*. There are official plugins (pmd
> is the latest example) whose current version logs these errors. *There
> is no workaround for end users.*
>
> - *There is not a clear path for plugin authors on how to fix this.*
> Googling for "maven localRepository deprecation" reports
> https://issue/
> s.apache.org%2Fjira%2Fbrowse%2FMNG-7706&data=05%7C01%7C%7Cb90c7f91bae7
> 44f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Yr2KZEyhff0YuluE%2FKA7pw55hUTFb1if%2Byqg6Nk3OVc%3D&reserved=0 as the fifth or sixth link (below the fold) which describes why this is reported but no clear recipe like "replace this dependency with this dependency. Use this injection."
> There are cryptic comments like the one on
> https://issue/
> s.apache.org%2Fjira%2Fprojects%2FMPMD%2Fissues%2FMPMD-368&data=05%7C01
> %7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaa
> aaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&
> sdata=EdP4C3EpOQyPGV3EY%2FOr1MGQACw%2FQQN6gbNSG8ZdBGI%3D&reserved=0
> which points at
> https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads "*Recent Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0 branch as well. With the upcoming major version this will be implicitly solved.*". Even if someone *wants* to contribute possible fixes, there is simply not enough information. And naively replacing the dependency leads to other errors (and probably stops working in older versions of maven).
>
>
> To summarize: From my PoV, *it is a bad decision to display
> deprecation messages that are intended for plugin authors to end
> users*. If the goal is to get plugin authors to change their code,
> this is the wrong way. It feels passive aggressive to me ("get end
> users to report bugs to plugins, so the plugin authors are compelled to fix this").
>
> Here are some suggestions:
>
> - the vast majority of builds have been designed for maven 3.x.x and
> they will keep using plugins that work with maven 3.x.x. So 3.x.x
> should not display warnings in the first place.
>
> - Removing these deprecated APIs is not an option for the 3.x.x cycle,
> so why display warnings about it? Introducing this in 3.8 -> 3.9 is
> wrong as there is an expectation with users that "upgrading a minor
> version should just work" (Backwards compatibility).
>
> - make it clear when things will stop working. Is that maven 4.x.x? Great.
> Having 4.0.0 show these warnings may be acceptable (as this is a new
> major version). Document that 4.0.0 will support them with warnings
> and 4.1.0 will no longer support them.
>
> - show these warnings in the developer tooling. Every maven developer
> uses the maven-plugin-plugin. Or plexus-component-metadata. Having
> those tools showing warnings (or errors) makes sense, because the
> audience are plugin developers and they can actually fix the problems.
>
> - Maven could have a "lint" or "-Wall" mode under a switch. If that
> switch is on, show these warnings. Otherwise, don't. The switch needs
> to be documented clearly. The argument "no one will use that" does not
> count. If it is documented, plugin developers will use it to find this
> type of problem. Build engineers will use it to find incompatibilities.
>
> - At the very minimum, ensure that all "official" maven plugins (the
> ones on
> https://maven/
> .apache.org%2Fplugins%2Findex.html&data=05%7C01%7C%7Cb90c7f91bae744f71
> b0808db53ebdd61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044
> 709515788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIi
> LCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=R4MgBcFJqomEFBH%2FzV07AjRJ2EMBiRmykeNUMGJFL6c%3D&reserved=0) are all updated before enabling this type of warning. At the very least, end users then *can* get rid of them by upgrading. The argument "This is a lot of work and we are only a few people that no one thanks for our hard work" is not an argument here. If this is a problem for code that is maintained as official plugins, then these warnings can not be added before all the plugins are updated.
>
> - Make it possible to help and provide patches. I know of many people
> that would chip in and help if there were a clear, actionable path to
> upgrade a plugin. Currently there is not and it would be good to create that.
>
>
> Feel free to agree, disagree, ignore. I am maintaining a set of base
> poms for starting and maintaining maven projects over at
> https://basep/
> om.org%2F&data=05%7C01%7C%7Cb90c7f91bae744f71b0808db53ebdd61%7C84df9e7
> fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638196044709515788%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0%3D%7C3000%7C%7C%7C&sdata=GdLjKtwepC%2FKFIfXJYibcCgu0KNr7FUN4QYBDcOy
> 3cA%3D&reserved=0
> and
> this is a pain that I go through every day when choosing to upgrade or
> use plugins. Apache Maven makes this harder than it should be.
>
> -h
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Some thoughts about the maven parameter deprecation messages
Posted by Romain Manni-Bucau <rm...@gmail.com>.
+1 very close to what I expressed on slack.
Think end user should also be able to see these warning to select a plugi
or evaluate a migration but at request -> new help plugin goal IMHO.
Le sam. 13 mai 2023 à 21:22, Henning Schmiedehausen <
henning@schmiedehausen.org> a écrit :
> Hi,
>
> [I wanted to write about this for a while]
>
> Maven has recently (3.9.x) started to log warning messages like this:
>
> *[WARNING] Parameter 'localRepository' is deprecated core expression; Avoid
> use of ArtifactRepository type. If you need access to local repository,
> switch to '${repositorySystemSession}' expression and get LRM from it
> instead.*
>
> I understand that this is an attempt to get plugin developers to replace
> APIs that are considered deprecated.
>
> Here is my take on this attempt:
>
> - The messages are shown to end users. *The end user is not the audience.*
> Plugin authors are. Most end users can not do anything about these errors
> but "upgrade the plugin version and hope for the best" or "file a report
> with the plugin authors (see
> https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 or
> https://issues.apache.org/jira/browse/MCHECKSTYLE-429)"
>
> - The messages are logged at "WARNING" level. So builds break for some
> users. *This is a bad user experience.* Best case scenario: Users work
> around (upgrade maven, downgrade maven, upgrade plugins, change build
> system setup). Worst case scenario: Use a different build tool so you just
> lost an user. Less users means fewer contributions, means less traction.
> That is how projects die.
>
> - *People need to build older code bases that use older versions of
> plugins*.
> They want to use "the `mvn` command" which may be installed by their OS or
> some packaging tool. They either experience a plethora of warnings "that
> were not there before" or need to install older versions of maven manually
> which is hard/impossible for many users. Spending time on "upgrading the
> build system", especially for larger projects is not an option (either
> skill-wise or willingness to spend time on a project that someone wants to
> evaluate or try out).
>
> - *The messages are not actionable*. There are official plugins (pmd is the
> latest example) whose current version logs these errors. *There is no
> workaround for end users.*
>
> - *There is not a clear path for plugin authors on how to fix this.*
> Googling for "maven localRepository deprecation" reports
> https://issues.apache.org/jira/browse/MNG-7706 as the fifth or sixth link
> (below the fold) which describes why this is reported but no clear recipe
> like "replace this dependency with this dependency. Use this injection."
> There are cryptic comments like the one on
> https://issues.apache.org/jira/projects/MPMD/issues/MPMD-368 which points
> at https://issues.apache.org/jira/browse/MCHECKSTYLE-429 which reads
> "*Recent
> Maven Reporting Impl is local localRepository-free. See my doxia-2.0.0
> branch as well. With the upcoming major version this will be implicitly
> solved.*". Even if someone *wants* to contribute possible fixes, there is
> simply not enough information. And naively replacing the dependency leads
> to other errors (and probably stops working in older versions of maven).
>
>
> To summarize: From my PoV, *it is a bad decision to display deprecation
> messages that are intended for plugin authors to end users*. If the goal is
> to get plugin authors to change their code, this is the wrong way. It feels
> passive aggressive to me ("get end users to report bugs to plugins, so the
> plugin authors are compelled to fix this").
>
> Here are some suggestions:
>
> - the vast majority of builds have been designed for maven 3.x.x and they
> will keep using plugins that work with maven 3.x.x. So 3.x.x should not
> display warnings in the first place.
>
> - Removing these deprecated APIs is not an option for the 3.x.x cycle, so
> why display warnings about it? Introducing this in 3.8 -> 3.9 is wrong as
> there is an expectation with users that "upgrading a minor version should
> just work" (Backwards compatibility).
>
> - make it clear when things will stop working. Is that maven 4.x.x? Great.
> Having 4.0.0 show these warnings may be acceptable (as this is a new major
> version). Document that 4.0.0 will support them with warnings and 4.1.0
> will no longer support them.
>
> - show these warnings in the developer tooling. Every maven developer uses
> the maven-plugin-plugin. Or plexus-component-metadata. Having those tools
> showing warnings (or errors) makes sense, because the audience are plugin
> developers and they can actually fix the problems.
>
> - Maven could have a "lint" or "-Wall" mode under a switch. If that switch
> is on, show these warnings. Otherwise, don't. The switch needs to be
> documented clearly. The argument "no one will use that" does not count. If
> it is documented, plugin developers will use it to find this type of
> problem. Build engineers will use it to find incompatibilities.
>
> - At the very minimum, ensure that all "official" maven plugins (the ones
> on https://maven.apache.org/plugins/index.html) are all updated before
> enabling this type of warning. At the very least, end users then *can* get
> rid of them by upgrading. The argument "This is a lot of work and we are
> only a few people that no one thanks for our hard work" is not an argument
> here. If this is a problem for code that is maintained as official plugins,
> then these warnings can not be added before all the plugins are updated.
>
> - Make it possible to help and provide patches. I know of many people that
> would chip in and help if there were a clear, actionable path to upgrade a
> plugin. Currently there is not and it would be good to create that.
>
>
> Feel free to agree, disagree, ignore. I am maintaining a set of base poms
> for starting and maintaining maven projects over at https://basepom.org
> and
> this is a pain that I go through every day when choosing to upgrade or use
> plugins. Apache Maven makes this harder than it should be.
>
> -h
>