+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 < [email protected]> 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 >
