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