Le sam. 13 mai 2023 à 22:13, Jeremy Landis <[email protected]> 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 <[email protected]> > Sent: Saturday, May 13, 2023 3:54 PM > To: Maven Developers List <[email protected]> > 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 < > [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://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: [email protected] > For additional commands, e-mail: [email protected] > >
