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 <herve.bout...@free.fr> 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 <herve.bout...@free.fr> > 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_plugin > > > > > > 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 < > anth...@whitford.com> > > > > > > > > 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 > > > > > > <thaush...@t-online.de> > > > > > > > > > > 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: users-unsubscr...@maven.apache.org > > > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
