Le dimanche 13 janvier 2019, 21:18:28 CET Robert Scholte a écrit : > On Sun, 13 Jan 2019 21:03:20 +0100, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > Le dimanche 13 janvier 2019, 20:22:15 CET Robert Scholte a écrit : > >> On Sun, 13 Jan 2019 18:48:29 +0100, Hervé BOUTEMY > >> <herve.bout...@free.fr> > >> > >> wrote: > >> > 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. > >> > > >> > I don't understand why you are talking about "latest": this has to do > >> > with > >> > versions injected from default lifecycle plugin bindings, whatever the > >> > version > >> > is > >> > >> I'm saying latest, because we recently started to add these > >> configurations > >> to the packaging-plugin, I'm just not sure if all plugins already > >> contain > >> it and since which version. For maven-jar-plugin it is 3.0.0 via > >> MJAR-183[1] > > > > IMHO, if we want to get the default bindings from configuration file > > inside a > > plugin jar instead or maven-core, we'll still need to define which plugin > > version to look at, or we'll have reproducibility issues > > then in any case, LATEST is not a choice > > Totally agree and this is exactly what's happening inside that file[1] I'm more thinking at the version of maven-jar-plugin to download to get access to that file
> > > [1] > https://github.com/apache/maven-jar-plugin/blob/master/src/main/filtered-res > ources/META-INF/plexus/components.xml#L67 > >> Robert > >> > >> [1] https://issues.apache.org/jira/browse/MJAR-183 > >> > >> > And it perfectly detects if on the 8 plugins benefiting from default > >> > lifecycle > >> > plugin binding, 6 have a versions defined but only 2 have not then > >> > inherit the > >> > version form the default lifecycle plugin bindings > >> > > >> >> It really matters where the default lifecycle bindings are comings > >> > >> from: > >> >> maven-core or packaging plugin. > >> > > >> > currently, they come from default-bindings.xml in core > >> > > >> > I'll prepare a Jira issue and a branch for review > >> > > >> > Regards, > >> > > >> > Hervé > >> > > >> >> 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 > > > > --------------------------------------------------------------------- > > 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
