yes, as Tibor says, with Maven 4 we'll start to move the default plugins versions in each Maven release (which we did not do before to keep stability, even if stability consequence is "old versions defined years ago")
which leads even more to the first answer: In other words, do not rely on the implied Super Parent Pom for defining plugin versions because it will not guarantee build stability. Instead, your pom hierarchy should explicitly declare the plugin versions to use. which leads to the whole discussion on how to manage easily and with stability plugins versions (through Corporate parent as a first level of answer, though wanted future pluginManagement import feature) Notice: I use "stability" term, because nowadays "reproducibility" is more "owned" by "Reproducible Builds" Regards, Hervé Le lundi 8 mars 2021, 00:52:41 CET Tibor Digana a écrit : > shortly, the Maven 3.7.0 had the Jira issue, and I think resolved it, with > bumped versions of default plugins to the most recent ones. > We stopped 3.7.0 and we are developing 4.0.0 now. > T > > On Sun, Mar 7, 2021 at 10:58 PM Greg Chabala <[email protected]> wrote: > > You're taking the discussion to a place about building something flexible, > > but the initial question from a user was 'Why is the Super POM pulling in > > an old version of maven-surefire-plugin by default?'. That's an issue that > > deserves to be solved. > > > > Maven 3.6.3's Super POM pulls in maven-surefire-plugin version 2.12.4, > > which was published 2012-09-24. Can we update the Super POM to something > > less ancient so that new users don't get burned by default? > > > > On Sun, Mar 7, 2021 at 2:07 PM Hervé BOUTEMY <[email protected]> > > > > wrote: > > > if you're talking about the little subset that we use for our default > > > packaging bindings [1], as you can see from the page, there is already a > > > version fixed by the bindings > > > > > > but: > > > 1. that ties you to a precise Maven version, which is something we want > > > > to > > > > > avoid > > > 2. it does not work for the many other plugins > > > > > > that's why any discussion is about making something flexible, and not > > > focusing > > > only on the few plugins used by default packagings > > > > > > regards, > > > > > > Hervé > > > > > > [1] https://maven.apache.org/ref/3.6.3/maven-core/default-bindings.html > > > > > > Le dimanche 7 mars 2021, 15:43:45 CET Mantas Gridinas a écrit : > > > > Maven does not provide all of those 5 thousand plugins by default, > > > > does > > > > > > it? > > > > > > > On Sun, Mar 7, 2021 at 11:39 AM Hervé BOUTEMY <[email protected]> > > > > > > wrote: > > > > > > But my question is why not add a feature where maven would > > > > > > produce a pom that contains the default plugins, repositories, and > > > > > > etc. > > > > > > > > > regardless of how verbose it would be? > > > > > > > > > > because there is a wide diversity of plugins (more than 5,000 in > > > > > > Central > > > > > > > > Repository), then nobody can define everything > > > > > > > > > > We need something extensible > > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > Le dimanche 7 mars 2021, 12:08:39 CET Mantas Gridinas a écrit : > > > > > > As far as I understand, depending on maven version, the list of > > > > > > default > > > > > > > > > plugin versions is different. One way I go around this is by using > > > > > > maven > > > > > > > > > wrapper, which also downloads the required maven version by the > > > > > > project. > > > > > > > > > The other way to go around this is to define all the plugin > > > > versions > > > > > > > > yourself. But my question is why not add a feature where maven > > > > would > > > > > > > > produce a pom that contains the default plugins, repositories, and > > > > > > etc. > > > > > > > > > regardless of how verbose it would be? > > > > > > > > > > > > On Sun, Mar 7, 2021, 12:46 Hervé BOUTEMY <[email protected]> > > > > > > wrote: > > > > > > > sorry, I don't understand: can you explain a little more what > > > > > > > you > > > > > > mean > > > > > > > > > > by > > > > > > > "produce the implied pom" and "some issues of > > > > > > > irreproducability"? > > > > > > > > > > > > > > Le dimanche 7 mars 2021, 10:44:08 CET Mantas Gridinas a écrit : > > > > > > > > Why not provide an ability to produce the implied pom > > > > explicitly > > > > > in > > > > > > > > > > > current project as well? This way you would get around some > > > > > > issues > > > > > > > > > > > of > > > > > > > > irreproducability. > > > > > > > > > > > > > > > > On Sun, Mar 7, 2021 at 9:29 AM Hervé BOUTEMY < > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > every existing plugin version can't be defined by Maven > > > > itself, > > > > > > > > > > > given > > > > > > > > > diversity of plugins > > > > > > > > > then we need something extensible > > > > > > > > > > > > > > > > > > there is https://issues.apache.org/jira/browse/MNG-5588 , > > > > > > > > > proposing to > > > > > > > > > mimic dependencyManagement import to get an equivalent > > > > > > > > > pluginManagement > > > > > > > > > import > > > > > > > > > > > > > > > > > > I love this idea, which is currently blocked by one stupid > > > > > > > > > concrete > > > > > > > > > > > > > > issue: > > > > > > > > > there is no "scope" field in plugin definition > > > > > > > > > > > > looking at model: > > > https://maven.apache.org/ref/3.6.3/maven-model/maven.html#class_pl > > > > > > > > > > > > ugin > > > > > > > > > > > > > > > > > > perhaps we could abuse plugin's "inherited" field, the same > > > > > > way we > > > > > > > > > > abused > > > > > > > > > > > > > > > > "scope" field of dependencies... > > > > > > > > > > > > > > > > > > Any taker to work with me on trying to code that? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > Le mardi 23 février 2021, 00:03:16 CET Greg Chabala a écrit : > > > > > > > > > > I agree with the recommendations made by Anthony, and that > > > > > > best > > > > > > > > > > practice > > > > > > > > > > > > > > > > > is > > > > > > > > > > to specify all versions explicitly. > > > > > > > > > > > > > > > > > > > > However, I am also empathetic to the concerns raised by > > > > > > Tilman. > > > > > > > > > > > > > When > > > > > > > > > > people > > > > > > > > > > compare Maven to other build tools and complain about the > > > > > > > > > > verbosity > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > POM > > > > > > > > > > files, a lot of that verbosity comes from having to > > > > > > > > > > specify > > > > > > > > > > versions > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > plugins, including plugins that are part of the default > > > > > > > > > > lifecycle. > > > > > > > > > > > > > > > > > > > > If we agree that Maven follows a convention over > > > > > > configuration > > > > > > > > > > design, > > > > > > > > > > > > > > > > > perhaps the Super POM should be updated to some more > > > > sensible > > > > > > > > > defaults. > > > > > > > > > > > > > > > > > While it may not be as reproducible to leave them > > > > > > unspecified, > > > > > > > > > > > > > it > > > > > > > > > > > > > > would > > > > > > > > > > > > > > > > > reduce the surprise to beginners when now very outdated > > > > > > plugin > > > > > > > > > > versions > > > > > > > > > > > > > > > > > are > > > > > > > > > > used by default. > > > > > > > > > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > On Mon, Feb 22, 2021 at 3:44 PM Anthony Whitford < > > > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > I recommend reading the “Important Note” found here: > > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in > > > > > > > > > > > > > > trod > > > > > > > > > > > uction < > > > > > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#in > > > > > > > > > > > > > > trod > > > > > > > > > > > uction> > > > > > > > > > > > > > > > > > > > > > > > Important Note: Always define each version of the > > > > plugins > > > > > > > > > > > > > > used > > > > > > > > > > > > by > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > > > > > build to guarantee the build reproducibility. A good > > > > > > practice > > > > > > > > > > > > > > is > > > > > > > > > > > to > > > > > > > > > > > specify > > > > > > > > > > > them in the <build><pluginManagement/></build> elements > > > > for > > > > > > > > > > > > > each > > > > > > > > > > > > > > build > > > > > > > > > > > > > > > > > > plugins. (Generally, you will define a > > > > <pluginManagement/> > > > > > > > > > > > > > element > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > parent POM.) For reporting plugins, specify each version > > > > in > > > > > > > > > > > > > the > > > > > > > > > > > <reporting><plugins/></reporting> elements (and surely > > > > > > > > > > > in > > > > > > the > > > > > > > > > > > > > > <build><pluginManagement/></build> elements too). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In other words, do not rely on the implied Super Parent > > > > Pom > > > > > > > > > > > > > for > > > > > > > > > > > defining > > > > > > > > > > > plugin versions because it will not guarantee build > > > > > > > > > > > > > > reproducibility. > > > > > > > > > > > > > > > > > > Instead, your pom hierarchy should explicitly declare > > > > > > > > > > > the > > > > > > > > > > > plugin > > > > > > > > > > > versions > > > > > > > > > > > to use. (Maintaining a corporate pom that may be used > > > > > > across > > > > > > > > > > projects > > > > > > > > > > > > > > > > > > might be a wise approach.) > > > > > > > > > > > > > > > > > > > > > > > On Feb 22, 2021, at 11:11 AM, Tilman Hausherr > > > > > > > > > > > > <[email protected]> > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > > > > I'm using maven 3.6.3 and the maven-surefire-plugin > > > > > > version > > > > > > > > > > > > > > > used > > > > > > > > > > > > > > in > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > > > > > build is 2.12.4 when the version is not specified, the > > > > > > > > > > > "effective" > > > > > > > > > > > version > > > > > > > > > > > is 2.10. For junit 5 one needs 2.22.2, see > > > > > > https://junit.org/junit5/docs/current/user-guide/#running-tests-build-> > > > > > > > > > > > > mave > > > > > > > > > > > > > > > > > > > > n > > > > > > > > > > > > > > > > > > > > > > > this is a pitfall for JUnit 5 users: > > > > > > > > > > > > https://stackoverflow.com/a/66313961/535646 > > > > > > > > > > > > who don't read the manual. Should I create a JIRA > > > > > > > > > > > > issue > > > > > > that > > > > > > > > > > > > > > > the > > > > > > > > > > > > super > > > > > > > > > > > > > > > > > > > > > > pom should be updated? Or is another plugin to "blame" > > > > for > > > > > the > > > > > > > > > > default > > > > > > > > > > > > > > > > > > version? > > > > > > > > > > > > > > > > > > > > > > > Tilman > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > - > > > > > > > > > > > > > > > To unsubscribe, e-mail: > > > [email protected] > > > > > > > > > > > > > > > For additional commands, e-mail: > > > [email protected] > > > > > > > > > ------------------------------------------------------------------ > > > > > > > > > > > > --- > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > - > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -------------------------------------------------------------------- > > > > > - > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
