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
