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 <herve.bout...@free.fr> 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 <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_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 < > > > > > > > > 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 > > --------------------------------------------------------------------- > 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
