Le sam. 20 mai 2023 à 10:22, Slawomir Jaranowski <s.jaranow...@gmail.com> a écrit :
> Hi, > > We have two kinds of causes which can emit warnings: > 1. wrong using of plugin by user like use deprecated or unexisting > parameters, using deprecated goals > 2. wrong implementation in plugin, eg scope, EOL components > > First group should be displayed - because the end user can fix their own > build > Second should be mentioned in brief mode. > > So I think we should split notification for such two groups and figure out > - discuss how to best inform each group separately. > Idea is interesting but when intended user should be able to switch some warning off without killing others (following the logic) so means a logger per plugin-goal (maven 4 enabling to tune these levels easily) or a prop per plugon-goal. Still think it doesnt belong to maven core but help plugin and should be enabled explicitly or not be. > pt., 19 maj 2023 o 21:32 Romain Manni-Bucau <rmannibu...@gmail.com> > napisał(a): > > > +1 to make NONE the default, know it defeats the purpose but this feature > > makes end user builds nasty whereas it should help them. > > > > I would also be +1 to make it a help:check-state goal rather than having > it > > in maven core where it is quite pointless IMHO as explained in earlier > > threads. > > > > Le ven. 19 mai 2023 à 21:17, Henning Schmiedehausen < > > henn...@schmiedehausen.org> a écrit : > > > > > Hi Gary, > > > > > > Seems we both work in similar places. :-) Looking at > > > > > > > > > https://github.com/apache/maven/commit/11d97e64e7e3fbed23d8e98abdd8c015a957ee82 > > > , > > > it seems that 3.9.3 (whenever that comes) will improve things; the > > default > > > logging is still not great but at least I can add > > > `<maven.plugin.validation>NONE</maven.plugin.validation>` to all my > > > projects get back to the pre-3.9.x state. @michaelo might like that as > > > well. > > > > > > @tamas I would have preferred if we did not add a "NONE" setting but > made > > > the "DEFAULT" value having no logging and replaced what is "DEFAULT" in > > > 3.9.2 with "SUMMARY" or "NORMAL" or something else. That way, the > default > > > state would be the same as it was with maven 3.8.x (which is IMHO the > > right > > > thing to call "default") and everyone who wants to actually log > warnings > > > can turn it on. > > > > > > Adding the property above to my poms is a stop-gap, as it emits a > warning > > > on pre-3.9.3 maven versions, something that I can not fix because older > > > versions of the build tool are "out there". I could put the property > > under > > > a profile but at that point it feels like fighting the tool. > > > > > > -h > > > > > > (pro-tip: Never call the value for a default setting "default". > "default" > > > is a state, not a value. If you want to change the "default" state, you > > are > > > now stuck with a value called "default") > > > > > > > > > > > > On Fri, May 19, 2023 at 11:47 AM Gary Gregory <garydgreg...@gmail.com> > > > wrote: > > > > > > > From this user's POV, I feel these warning force me to spin my > wheels: > > > If I > > > > have old plugins I can update their versions, and then I still get > the > > > > warnings, none of which I can do anything about. I can do something > > about > > > > compiler warnings, I can do nothing about these. > > > > > > > > I am left to explain up and down the food chain with hand handwaving > > why > > > > these warnings are "ok" :-( > > > > > > > > Gary > > > > > > > > > > > > On Fri, May 19, 2023, 14:15 Henning Schmiedehausen < > > > > henn...@schmiedehausen.org> wrote: > > > > > > > > > Hi Tamas, > > > > > > > > > > Thanks for the quick response. > > > > > > > > > > On Fri, May 19, 2023 at 2:35 AM Tamás Cservenák < > ta...@cservenak.net > > > > > > > > wrote: > > > > > > > > > > > Howdy, > > > > > > > > > > > > So, have a small local change, probably to go with 3.9.3. > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > [WARNING] * org.basepom.maven:inline-maven-plugin:1.0.1 > > > > > > [WARNING] Declared at location(s): > > > > > > [WARNING] * org.jdbi:jdbi3-core:3.38.3-SNAPSHOT > (core/pom.xml) @ > > > > line > > > > > > 145 > > > > > > [WARNING] Used in module(s): > > > > > > [WARNING] * org.jdbi:jdbi3-core:3.38.3-SNAPSHOT (core/pom.xml) > > > > > > [WARNING] Plugin issue(s): > > > > > > [WARNING] * Plugin descriptor should not contain these Maven > > > > > artifacts: > > > > > > [org.apache.maven:maven-artifact:3.8.4, > > > > > > org.apache.maven:maven-settings-builder:3.8.4, > > > > > > org.apache.maven:maven-repository-metadata:3.8.4, > > > > > > org.apache.maven:maven-builder-support:3.8.4, > > > > > > org.apache.maven:maven-core:3.8.4, > > > > > > org.apache.maven:maven-resolver-provider:3.8.4, > > > > > > org.apache.maven:maven-settings:3.8.4, > > > > > > org.apache.maven:maven-plugin-api:3.8.4, > > > > > > org.apache.maven:maven-model-builder:3.8.4, > > > > > > org.apache.maven:maven-model:3.8.4] > > > > > > > > > > > > > > > > This has *zero* meaning to the person running the build. And it > still > > > > does > > > > > not help the plugin author either. Because they (I) used the maven > > tool > > > > > chain that was current at the point in time the plugin was created. > > > There > > > > > is still no actionable advice in here and there is no link to any > > > > > documentation that tells a plugin author what the root cause is and > > > what > > > > to > > > > > do. Developers can now either do the "update everything and pray", > an > > > > > approach that worked exceedingly well with maven dependencies (look > > at > > > > all > > > > > the incompatibilities with the 4.0.0-M<x> components) or turn > around > > to > > > > the > > > > > maven mailing list asking "what should I do". > > > > > > > > > > You need to write documentation that helps your users. All the > error > > > > > messages and warnings and "this is wrong, fix it" messages to users > > do > > > > not > > > > > help. > > > > > > > > > > This passive-aggressive attempt to surface problems in an obscure > way > > > to > > > > > the end user and hope that "they file bugs with the plugin authors" > > is > > > a > > > > > terrible way to instigate change. > > > > > > > > > > I understand that there is limited developer time on Maven and this > > > looks > > > > > tempting as the "simplest path" but all you have accomplished is > > reduce > > > > > trust. "maven suddenly reports problems that were not there before. > > > Were > > > > > those always there? Are my builds still good? Do my older projects > > > still > > > > > build?" > > > > > > > > > > Surfacing non-actionable warnings or errors to a non-audience is a > > > no-no > > > > > for any user experience; this is UX 101. > > > > > > > > > > For Jdbi, I still get complaints > > > > > about org.apache.maven.plugins:maven-pmd-plugin, > > > > > org.apache.maven.plugins:maven-javadoc-plugin, > > > > > org.apache.maven.plugins:maven-source-plugin, > > > > > org.apache.maven.plugins:maven-dependency-plugin. > > > > > So even the official maven plugins have not gotten this right. Of > > > course > > > > > you can say "time heals all wounds". That is not true, because > there > > is > > > > > attrition by people switching tools. Heck, the ASF is now running a > > > > gradle > > > > > enterprise server. > > > > > > > > > > You need to turn all of these warnings *OFF* and document the > > existence > > > > of > > > > > the switch *and* give developer documentation what you expect > plugin > > > > users > > > > > *to do*. And then evangelize that. That will get your allies (which > > are > > > > the > > > > > plugin authors that will *want* to fix the problems) to help you. > > Not > > > > > throw out another release with slightly tweaked warnings. > > > > > > > > > > Calling "maven 3.9 is about the journey to 4.0" is ridiculous. > Maven > > > 3.9 > > > > is > > > > > a, by definition, fully backwards compatible release of Apache > Maven > > > 3.x. > > > > > If you need a journey, then release Maven 4.0.0 as that stepping > > stone > > > > and > > > > > then 5.0 as a backwards incompatible version. Maven 4 has been in > > > > > development for many years and developer uptake will take a long > > time, > > > > > especially if all old builds break left and right. You may even end > > up > > > > > having to call it "mvn4" and not "mvn" to not break build scripts > in > > > > > countless organizations. > > > > > > > > > > -h > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Sławomir Jaranowski >
