> 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 <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 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
