>> However, it seems that the only use case for upgrading the default plugin versions is compatibility with some specific Java version?
Gabriel, Java version is not the only one reason. There is API version as well and bug fixing. These plugins are especially important because they are bound to the build life cycle. Scaring with making new plugin updates in Maven Core by the same development group would mean almost the same that we did not trust the plugin releases we have made. >> added value by updating this service from outside of either a maven core I agree with Robert. The XML should be externalized. I understand it the way that this XML would be in the Maven distribution and not in JAR file. There is a similarity with JavaEE idea where configuration is not embedded in the software - apart, but that's a different story. On Mon, Jan 14, 2019 at 11:59 PM Gabriel Belingueres <belingue...@gmail.com> wrote: > I think I'm joining late to this thread. +1 to showing a warning message. > > However, it seems that the only use case for upgrading the default plugin > versions is compatibility with some specific Java version? > > How about developing a plugin that "recommends" specific plugin versions > based on the source/target java version? recommendation can be based on a > downloaded file/database/artifact/web service that the plugin parses? This > way you can add some added value by updating this service from outside of > either a maven core or specific plugin's release cycle. > > El lun., 14 de ene. de 2019 a la(s) 10:34, Hervé BOUTEMY ( > herve.bout...@free.fr) escribió: > > > PR also created :) > > https://github.com/apache/maven/pull/233 > > > > Le lundi 14 janvier 2019, 12:06:40 CET Hervé BOUTEMY a écrit : > > > MNG-6562 Jira issue [1] and Git branch [2] created: please review and > > > comment > > > > > > I'll start to work on the new parent POM that locks down versions of > > plugins > > > from default lifecycle bindings: see MPOM-215 [3] I'll do it in a > > personal > > > GitHub git repo first while we choose the final name: > > > maven-default-plugins? > > > > > > Regards, > > > > > > Hervé > > > > > > [1] https://issues.apache.org/jira/browse/MNG-6562 > > > > > > [2] > > > > > > https://github.com/apache/maven/commit/05bc5c15dd37290e51190c6aa3fe4eb4a5bc > > > e62c > > > > > > [3] https://issues.apache.org/jira/browse/MPOM-215 > > > > > > Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit : > > > > This is indeed a good approach. > > > > The first group doesn't care about this warning, the second one > should. > > > > > > > > Hervé, can you confirm that in case of *only* specifying the latest > > > > maven-jar-plugin or maven-war-plugin or other packaging plugin, you > > won't > > > > get these warnings. > > > > It really matters where the default lifecycle bindings are comings > > from: > > > > maven-core or packaging plugin. > > > > > > > > All this is an interesting feature worth for 3.7.0 > > > > > > > > thanks, > > > > Robert > > > > > > > > On Sun, 13 Jan 2019 04:39:15 +0100, 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 > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
