Maven superpom, JUnit 5 and Spring

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven superpom, JUnit 5 and Spring

Tilman Hausherr
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-maven
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Anthony Whitford
I recommend reading the “Important Note” found here:  https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction <https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction>

> 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 <[hidden email]> 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-maven
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Greg Chabala
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 <[hidden email]>
wrote:

> I recommend reading the “Important Note” found here:
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction
> <
> https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introduction
> >
>
> > 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 <[hidden email]>
> 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-maven
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Hervé BOUTEMY
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 <[hidden email]>
>
> wrote:
> > I recommend reading the “Important Note” found here:
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > uction <
> > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > 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 <[hidden email]>
> >
> > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Mantas Gridinas
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 <[hidden email]> 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 <[hidden email]>
> >
> > wrote:
> > > I recommend reading the “Important Note” found here:
> > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > > uction <
> > > https://maven.apache.org/guides/mini/guide-configuring-plugins.html#introd
> > > 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 <[hidden email]>
> > >
> > > 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Hervé BOUTEMY
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 <[hidden email]> 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 <[hidden email]>
> > >
> > > 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
> > > > > <[hidden email]>
> > > >
> > > > 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: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Mantas Gridinas
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 <[hidden email]> 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > >
> > > > 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
> > > > > > <[hidden email]>
> > > > >
> > > > > 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: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Hervé BOUTEMY
> 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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <
> >
> > [hidden email]>
> >
> > > > > 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
> > > > > > > <[hidden email]>
> > > > > >
> > > > > > 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: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Mantas Gridinas
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > >
> > > 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 <
> > >
> > > [hidden email]>
> > >
> > > > > > 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
> > > > > > > > <[hidden email]>
> > > > > > >
> > > > > > > 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: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Hervé BOUTEMY
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > > >
> > > > 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 <
> > > >
> > > > [hidden email]>
> > > >
> > > > > > > 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
> > > > > > > > > <[hidden email]>
> > > > > > > >
> > > > > > > > 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: [hidden email]
> > > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > > ------------------------------------------------------------------
> > > > > > ---
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Greg Chabala
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> 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 <
> [hidden email]>
> > > > >
> > > > > 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 <
> > > > >
> > > > > [hidden email]>
> > > > >
> > > > > > > > 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
> > > > > > > > > > <[hidden email]>
> > > > > > > > >
> > > > > > > > > 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:
> [hidden email]
> > > > > > > > > > For additional commands, e-mail:
> [hidden email]
> > > > > > >
> > > > > > >
> ------------------------------------------------------------------
> > > > > > > ---
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> --------------------------------------------------------------------
> > > > > > -
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Tibor Digana
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> > 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 <[hidden email]>
> > 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 <
> > [hidden email]>
> > > > > >
> > > > > > 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 <
> > > > > >
> > > > > > [hidden email]>
> > > > > >
> > > > > > > > > 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
> > > > > > > > > > > <[hidden email]>
> > > > > > > > > >
> > > > > > > > > > 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:
> > [hidden email]
> > > > > > > > > > > For additional commands, e-mail:
> > [hidden email]
> > > > > > > >
> > > > > > > >
> > ------------------------------------------------------------------
> > > > > > > > ---
> > > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > > > > > >
> > > > > > >
> > --------------------------------------------------------------------
> > > > > > > -
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: Maven superpom, JUnit 5 and Spring

Hervé BOUTEMY
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 <[hidden email]> 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 <[hidden email]>
> >
> > 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 <[hidden email]>
> > >
> > > 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 <[hidden email]>
> > >
> > > 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 <
> > >
> > > [hidden email]>
> > >
> > > > > > > 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 <
> > > > > > >
> > > > > > > [hidden email]>
> > > > > > >
> > > > > > > > > > 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
> > > > > > > > > > > > <[hidden email]>
> > > > > > > > > > >
> > > > > > > > > > > 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:
> > > [hidden email]
> > >
> > > > > > > > > > > > For additional commands, e-mail:
> > > [hidden email]
> > >
> > >
> > > ------------------------------------------------------------------
> > >
> > > > > > > > > ---
> > > > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > > > For additional commands, e-mail: [hidden email]
> > >
> > > --------------------------------------------------------------------
> > >
> > > > > > > > -
> > > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > >
> > > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > -
> > > > > To unsubscribe, e-mail: [hidden email]
> > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email]
> > > For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]