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
<henn...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
