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 > >
