thank you for the improved message: yes, we'll need help to define the right message since it will be seen by many many users who are quite new to Maven...
To help on plugins upgrade, there is versions:display-plugin-updates https://www.mojohaus.org/versions-maven-plugin/display-plugin-updates-mojo.html Perhaps a FAQ page on Maven site will be useful Regards, Hervé Le dimanche 13 janvier 2019, 07:45:19 CET David Jencks a écrit : > I think the warning is a really good idea but I don’t think this wording > will mean anything to the average maven user, as I don’t understand from it > what I should do to fix the problem. How about something like: “Specify > explicit versions for these plugins in the project pom or an ancestor > pom:...” > > If someone is maintaining plug-in versions manually is there a tool to point > out all the upgrade possibilities? > > Thanks > David Jencks > Sent from my iPhone > > > On Jan 12, 2019, at 7:39 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > > > we have 2 opposite objectives: > > - make default near-empty pom work at best, > > - but force people to have defined plugins versions (then not really empty > > pom) to get stable build > > > > and I checked about the warning message: I was wrong, there is no warning > > message when plugins without versions are injected by default lifecycle > > bindings> > > Just test for yourself following pom.xml from any beginner: > > <project> > > > > <modelVersion>4.0.0</modelVersion> > > <groupId>com.mycompany.app</groupId> > > <artifactId>my-app</artifactId> > > <version>1.0-SNAPSHOT</version> > > > > </project> > > > > it works = what we expect to ease newcomers experience > > but there is no warning... > > > > IMHO, this is where we need to improve the tool, by adding a warning: > > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that > > displays: [WARNING] > > [WARNING] Some problems were encountered while building the effective > > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT [WARNING] Using > > default plugins versions from bindings: > > [org.apache.maven.plugins:maven-clean-plugin, > > org.apache.maven.plugins:maven-install-plugin, > > org.apache.maven.plugins:maven-resources-plugin, > > org.apache.maven.plugins:maven-surefire-plugin, > > org.apache.maven.plugins:maven-compiler-plugin, > > org.apache.maven.plugins:maven-jar-plugin, > > org.apache.maven.plugins:maven-deploy-plugin, > > org.apache.maven.plugins:maven-site-plugin] [WARNING] > > [WARNING] It is highly recommended to fix these problems because they > > threaten the stability of your build. [WARNING] > > [WARNING] For this reason, future Maven versions might no longer support > > building such malformed projects. [WARNING] > > > > With this warning, and a parent pom to have an easy fix (instead of 8 > > plugins versions definition), IMHO, we have what we strongly need. > > > > And even better, with this warning in place to avoid people to continue to > > rely on default plugins versions (because of the nasty warning), I could > > find upgrading default plugins versions not an issue any more!!! > > > > Should we try to go this route? > > > > Regards, > > > > Hervé > > > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit : > >> The original plan was to make plugin version mandatory. Perhaps 3.7.0 is > >> the time to do that, with a CLI option (to be removed after 3.7.x) to > >> pull > >> in the 3.6.x default versions if your pom is missing plugin versions. > >> > >> The warning has been there long enough. Let’s pull the trigger. > >> > >>> On Sat 12 Jan 2019 at 21:34, Tibor Digana <tibordig...@apache.org> > >>> wrote: > >>> I have a strong reason to update Surefire due to new JRE versions have > >>> been > >>> updated too many times last two years. > >>> They required a fix done within a few days and some of them are shaking > >>> on > >>> the chair... > >>> Our Maven Core is stable and Java 9+ ready but the obsolete plugins are > >>> not. > >>> I want only the same compatibility with default plugins because people > >>> do > >>> not see these plugins as a distinct community. They are both Maven and > >>> plugins from us Apache, so they most probably would expect it consistent > >>> altogether. > >>> Makes sense? > >>> > >>> On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels <e...@zusammenkunft.net> > >>> > >>> wrote: > >>>> I think that’s a real bad idea if you have to do local modifications to > >>>> get to a working build environment. Maven is all about not requiring > >>>> you > >>> > >>> to > >>> > >>>> do that (anymore). So even requiring a certain Maven Version does not > >>>> fit > >>>> in that pattern (although unavoidable if you do not want to work with > >>>> wrappers). > >>>> > >>>> So this means: keep old standard versions and overwrite them always in > >>>> poms. (And it means the amount of default versions should be reduced or > >>> > >>> at > >>> > >>>> least not add new ones) > >>>> > >>>> Gruss > >>>> Bernd > >>>> -- > >>>> http://bernd.eckenfels.net > >>>> > >>>> ________________________________ > >>>> Von: Robert Scholte <rfscho...@apache.org> > >>>> Gesendet: Samstag, Januar 12, 2019 5:07 PM > >>>> An: Maven Developers List > >>>> Betreff: Re: Update versions of all plugins in default-bindings.xml > >>>> > >>>> I had chats with both Adam Bien and Sebastian Daschner asking for a > >>> > >>> better > >>> > >>>> way to work with a simple high-speed throw-away development pom. > >>>> > >>>> They are both working a lot with Java EE applications and want to rely > >>>> on > >>>> defaults as much as possible. > >>>> So in a way they don't care about plugin versions. > >>>> They only case about things in poms that does matter (unique to that > >>>> project): dependencies > >>>> However, with Java 9+ stuff they are forced to specify plugins with > >>>> more > >>>> recent versions right now. > >>>> > >>>> So here comes the idea of extensions: you can put it in your > >>> > >>> maven/lib/ext > >>> > >>>> ONCE and your pom is again as clean as possible. > >>>> > >>>> This seems to be a common way of work for some kind of developers and > >>>> it > >>>> would make sense if Maven could support this. > >>>> > >>>> To me default plugin versions are bound to a minor Maven release, not a > >>>> major. > >>>> When starting with Maven and create your first hello world, it should > >>> > >>> work > >>> > >>>> out of the box. > >>>> Right now if you are using Java 11, you'll probably hit issues because > >>>> some defaults won't work anymore. > >>>> That's a bad thing to me and a valid reason to upgrade the plugins. > >>>> > >>>> I do understand Hervé concerns. We should motivate people to lock their > >>>> plugins in their pom. > >>>> Most of all the packaging-plugin is important. AFAIK all 3.0+ versions > >>>> contain plugin bindings, in which case it should be good enough if that > >>>> plugin is at least specified. > >>>> > >>>> thanks, > >>>> Robert > >>>> > >>>> On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY > >>>> <herve.bout...@free.fr > >>>> > >>>> wrote: > >>>>> original idea, let's try to evaluate :) > >>>>> > >>>>> IMHO this could work for packaging plugins in default lifecycle, that > >>> > >>> are > >>> > >>>>> defined in default-bindings.xml, but would not for other lifecycles > >>> > >>> that > >>> > >>>>> are > >>>>> configured in components.xml (without copy/pasting content not related > >>> > >>> to > >>> > >>>>> plugins) > >>>>> > >>>>> I don't think an extension would be easier to use than a pom.xml, it's > >>>>> even > >>>>> IMHO worse since you have to create a new file in a new directory. > >>>>> > >>>>> one question is: is there a use case that an extension would permit > >>> > >>> that > >>> > >>>>> a > >>>>> parent pom would not? > >>>>> the only case I see is if a user does not want to change his parent > >>>>> pom > >>>>> (or > >>>>> cannot): since we don't have "pluginManagement import" (like we have > >>> > >>> for > >>> > >>>>> dependency management). > >>>>> > >>>>> > >>>>> I think for the moment that a parent pom would be more classical, > >>> > >>> easier > >>> > >>>>> to > >>>>> explain: I don't really see a clear benefit to do the job as an > >>> > >>> extension > >>> > >>>>> instead, this would IMHO make the change harder for users > >>>>> > >>>>> Regards, > >>>>> > >>>>> Hervé > >>>>> > >>>>> Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte a écrit : > >>>>>> Just wondering, can this be solved by an extension? > >>>>>> > >>>>>> So instead of changing this in Maven Core itself, people can add an > >>>>>> extension to Maven with the latest+stable releases. > >>>>>> > >>>>>> Hervé and I already discovered that current focus is mainly on > >>>>>> plugins > >>>>>> right now. We should also work on extensions. > >>>>>> > >>>>>> Robert > >>>>>> > >>>>>> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY > >>>>>> <herve.bout...@free.fr> > >>>>>> > >>>>>> wrote: > >>>>>>> Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a écrit : > >>>>>>>> ok, Herve, the fact is that these plugins have been updated from > >>>>>> > >>>>>> time to > >>>>>> > >>>>>>>> time. > >>>>>>> > >>>>>>> yes, we did it in the past (years ago, look at the history) and > >>>>>>> went > >>>>>> > >>>>>> to > >>>>>> > >>>>>>> the > >>>>>>> conclusion we should not do that to improve reproducibility, unless > >>>>>>> there is a > >>>>>>> strong reason to do it sometimes on some specific plugins > >>>>>>> = what I'm trying to explain, for the moment without much success > >>>>>>> > >>>>>>> > >>>>>>> What we could do would be to create a new POM to use as parent POM, > >>>>>> > >>>>>> that > >>>>>> > >>>>>>> would > >>> > >>>>>>> define the versions of every plugin from the default lifecycles: > >>> this > >>> > >>>>>>> would > >>>>>>> avoid to have everybody to write the full list of plugins (which is > >>> > >>> a > >>> > >>>>>>> pain: I > >>>>>>> know because in MARCHETYPES-54 [1] I added the list in Maven > >>>>>>> Archetypes...) > >>>>>>> We could name it "maven-default-plugins", or if somebody has a > >>> > >>> better > >>> > >>>>>>> idea. > >>>>>>> This way, changing plugins versions would not be tied to changing > >>>>>> > >>>>>> Maven > >>>>>> > >>>>>>> version > >>>>>>> > >>>>>>> WDYT? > >>>>>>> > >>>>>>> Regards, > >>>>>>> > >>>>>>> Hervé > >>>>>>> > >>>>>>> [1] https://issues.apache.org/jira/browse/MARCHETYPES-54 > >>>>>>> > >>>>>>>> How can we be on safe side with these updates? What is mandatory > >>>>>>>> to > >>>>>> > >>>>>> do > >>>>>> > >>>>>>>> for > >>>>>>>> such upgrade? > >>>>>>>> > >>>>>>>> On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY < > >>> > >>> herve.bout...@free.fr > >>> > >>>>>>>> wrote: > >>>>>>>>> As I wrote in many Jira issues over years on this topic, I'm not > >>> > >>> in > >>> > >>>>>>>> favor > >>>>>>>> > >>>>>>>>> of > >>>>>>>>> that > >>>>>>>>> > >>>>>>>>> To me, staying with the same default plugins versions from Maven > >>>>>>>> > >>>>>>>> version > >>>>>>>> > >>>>>>>>> to > >>>>>>>>> Maven version is a feature: nobody should expect to change his > >>>>>> > >>>>>> Maven > >>>>>> > >>>>>>>>> version > >>>>>>>>> to change the plugins versions > >>>>>>>>> The best practice is to define plugins versions in your pom.xml > >>> > >>> (or > >>> > >>>>>>>>> parent). > >>>>>>>>> Getting very old versions of plugins by default is the best > >>>>>> > >>>>>> additional > >>>>>> > >>>>>>>>> feature > >>>>>>>>> we have after the WARN "plugin version not defined" > >>>>>>>>> > >>>>>>>>> Then IMHO, upgrading default plugins versions is a bad idea, is > >>>>>>>>> a > >>>>>> > >>>>>> bad > >>>>>> > >>>>>>>>> message > >>>>>>>>> = "you can continue to ignore the WARN on plugins versions and > >>>>>> > >>>>>> still > >>>>>> > >>>>>>>> get > >>>>>>>> > >>>>>>>>> newest and latest plugins" > >>>>>>>>> > >>>>>>>>> this leads IMHO to one (bad) reason for people to require Maven > >>>>>>>> > >>>>>>>> Wrapper > >>>>>>>> > >>>>>>>>> I know, this is counter intuitive, that's why it is required to > >>>>>> > >>>>>> really > >>>>>> > >>>>>>>>> take a > >>>>>>>>> moment to think about it > >>>>>>>>> > >>>>>>>>> Regards, > >>>>>>>>> > >>>>>>>>> Hervé > >>>>>>>>> > >>>>>>>>> Le jeudi 10 janvier 2019, 17:08:57 CET Tibor Digana a écrit : > >>>>>>>>>> Why we use old versions in default-bindings.xml? > >>>>>>>>>> Can we update all versions in 3.6.1 release? > >>>>>>>>>> > >>>>>>>>>> Here is MNG-6557 which is related to Surefire but I guess this > >>>>>> > >>>>>> Jira > >>>>>> > >>>>>>>>>> issue > >>>>>>>>>> can be freely related to all plugins. > >>>>>>>>>> > >>>>>>>>>> WDYT? > >>>>>>>>>> Any objections to update all plugins and assign this issue in > >>>>>> > >>>>>> 3.6.1? > >>>>>> > >>>>>>>>>> Cheers > >>>>>>>>>> Tibor > >>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> > >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >>> --------------------------------------------------------------------- > >>> > >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>>>> --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
