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
