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
