You are viewing a plain text version of this content. The canonical link for it is here.
Posted to release-discuss@apache.org by Slawomir Jaranowski <s....@gmail.com> on 2023/06/05 22:28:46 UTC
ASF Maven parent pom and use properties to define the versions of plugins
Hi,
I want to introduce properties to define versions of plugins.
I have prepared PR [1] and we have a discussion about properties schema for
such purposes.
Because AFS Maven parent is used by other ASF projects, and such changes
can be difficult to change in the next release, I want to know other
opinions.
[1] https://github.com/apache/maven-apache-parent/pull/155
--
Sławomir Jaranowski
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Gary Gregory <ga...@gmail.com>.
I agree with Christopher FWIW, I don't see the technical reason to not do
this. I'd use this feature in Apache Commons Parent and other POMs when
needed for example.
Gary
On Wed, Jun 7, 2023, 18:42 Christopher <ct...@apache.org> wrote:
> It doesn't matter that some projects are stuck on old versions, or
> their reasons why. That's not a valid technical reason to -1 the
> proposed changes, as it has nothing to do with the proposed changes.
>
> The proposal was to use properties in the Apache parent POM (MPOM) to
> make it easier for projects that use the parent POM to override the
> versions of the plugins that are defined in it, if they wish to. This
> doesn't affect any project's choice to use one version over another
> for the parent POM, or to use one plugin version that might be
> declared with a managed version in the parent POM over another.
>
> The only thing this does is make it slightly easier to override stuff
> defined in the parent POM (and even more slightly easier to maintain
> the parent POM itself, because diffs will be slightly smaller when
> updating any default versions).
>
> So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
> issue that you need fixed for your project, you don't have to wait for
> a new release of MPOM... you can easily just do:
>
> ```xml
> <properties>
> <!-- naming convention still being discussed, but this is an example
> -->
> <version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
> </properties>
> ```
>
> Previously, you would have had to do:
>
> ```xml
> <build>
> <pluginManagement>
> <plugins>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>3.11.1</version>
> </plugins>
> </pluginManagement>
> </build>
> ```
>
> You can still use the latter, if you really want to.
>
> So, I don't understand Allen's -1 on the basis that some people need
> to use specific versions of the parent POM, or even specific versions
> of specific plugins. The proposed change only makes that easier... and
> only if they want to take the easier path, which is still optional.
> Whether or not some plugin versions cause problems or not for users is
> irrelevant.... this only makes it easier for users to choose the
> version they need. Otherwise, it has no impact to them whatsoever.
>
> On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> > >
> > >
> > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <
> s.jaranowski@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I want to introduce properties to define versions of plugins.
> > >> I have prepared PR [1] and we have a discussion about properties
> schema for
> > >> such purposes.
> > >>
> > >> Because AFS Maven parent is used by other ASF projects, and such
> changes
> > >> can be difficult to change in the next release, I want to know other
> > >> opinions.
> > >
> > > -1
> > >
> > > Some projects are stuck on old versions of the pom because newer ones
> introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on
> v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> >
> > > So no, the parent pom needs to define less, not more.
> > >
> > > [I’m almost to the point of just forking the thing and removing bits
> because it is so wildly unreliable.]
> > >
> >
> >
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
Forgive my typo.... there should be an extra layer of `<plugin> ...
</plugin>` in the latter example.
On Wed, Jun 7, 2023 at 6:41 PM Christopher <ct...@apache.org> wrote:
>
> It doesn't matter that some projects are stuck on old versions, or
> their reasons why. That's not a valid technical reason to -1 the
> proposed changes, as it has nothing to do with the proposed changes.
>
> The proposal was to use properties in the Apache parent POM (MPOM) to
> make it easier for projects that use the parent POM to override the
> versions of the plugins that are defined in it, if they wish to. This
> doesn't affect any project's choice to use one version over another
> for the parent POM, or to use one plugin version that might be
> declared with a managed version in the parent POM over another.
>
> The only thing this does is make it slightly easier to override stuff
> defined in the parent POM (and even more slightly easier to maintain
> the parent POM itself, because diffs will be slightly smaller when
> updating any default versions).
>
> So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
> issue that you need fixed for your project, you don't have to wait for
> a new release of MPOM... you can easily just do:
>
> ```xml
> <properties>
> <!-- naming convention still being discussed, but this is an example -->
> <version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
> </properties>
> ```
>
> Previously, you would have had to do:
>
> ```xml
> <build>
> <pluginManagement>
> <plugins>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>3.11.1</version>
> </plugins>
> </pluginManagement>
> </build>
> ```
>
> You can still use the latter, if you really want to.
>
> So, I don't understand Allen's -1 on the basis that some people need
> to use specific versions of the parent POM, or even specific versions
> of specific plugins. The proposed change only makes that easier... and
> only if they want to take the easier path, which is still optional.
> Whether or not some plugin versions cause problems or not for users is
> irrelevant.... this only makes it easier for users to choose the
> version they need. Otherwise, it has no impact to them whatsoever.
>
> On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> > >
> > >
> > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I want to introduce properties to define versions of plugins.
> > >> I have prepared PR [1] and we have a discussion about properties schema for
> > >> such purposes.
> > >>
> > >> Because AFS Maven parent is used by other ASF projects, and such changes
> > >> can be difficult to change in the next release, I want to know other
> > >> opinions.
> > >
> > > -1
> > >
> > > Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> >
> > > So no, the parent pom needs to define less, not more.
> > >
> > > [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
> > >
> >
> >
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
Forgive my typo.... there should be an extra layer of `<plugin> ...
</plugin>` in the latter example.
On Wed, Jun 7, 2023 at 6:41 PM Christopher <ct...@apache.org> wrote:
>
> It doesn't matter that some projects are stuck on old versions, or
> their reasons why. That's not a valid technical reason to -1 the
> proposed changes, as it has nothing to do with the proposed changes.
>
> The proposal was to use properties in the Apache parent POM (MPOM) to
> make it easier for projects that use the parent POM to override the
> versions of the plugins that are defined in it, if they wish to. This
> doesn't affect any project's choice to use one version over another
> for the parent POM, or to use one plugin version that might be
> declared with a managed version in the parent POM over another.
>
> The only thing this does is make it slightly easier to override stuff
> defined in the parent POM (and even more slightly easier to maintain
> the parent POM itself, because diffs will be slightly smaller when
> updating any default versions).
>
> So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
> issue that you need fixed for your project, you don't have to wait for
> a new release of MPOM... you can easily just do:
>
> ```xml
> <properties>
> <!-- naming convention still being discussed, but this is an example -->
> <version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
> </properties>
> ```
>
> Previously, you would have had to do:
>
> ```xml
> <build>
> <pluginManagement>
> <plugins>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>3.11.1</version>
> </plugins>
> </pluginManagement>
> </build>
> ```
>
> You can still use the latter, if you really want to.
>
> So, I don't understand Allen's -1 on the basis that some people need
> to use specific versions of the parent POM, or even specific versions
> of specific plugins. The proposed change only makes that easier... and
> only if they want to take the easier path, which is still optional.
> Whether or not some plugin versions cause problems or not for users is
> irrelevant.... this only makes it easier for users to choose the
> version they need. Otherwise, it has no impact to them whatsoever.
>
> On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> > >
> > >
> > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I want to introduce properties to define versions of plugins.
> > >> I have prepared PR [1] and we have a discussion about properties schema for
> > >> such purposes.
> > >>
> > >> Because AFS Maven parent is used by other ASF projects, and such changes
> > >> can be difficult to change in the next release, I want to know other
> > >> opinions.
> > >
> > > -1
> > >
> > > Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> >
> > > So no, the parent pom needs to define less, not more.
> > >
> > > [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
> > >
> >
> >
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Gary Gregory <ga...@gmail.com>.
I agree with Christopher FWIW, I don't see the technical reason to not do
this. I'd use this feature in Apache Commons Parent and other POMs when
needed for example.
Gary
On Wed, Jun 7, 2023, 18:42 Christopher <ct...@apache.org> wrote:
> It doesn't matter that some projects are stuck on old versions, or
> their reasons why. That's not a valid technical reason to -1 the
> proposed changes, as it has nothing to do with the proposed changes.
>
> The proposal was to use properties in the Apache parent POM (MPOM) to
> make it easier for projects that use the parent POM to override the
> versions of the plugins that are defined in it, if they wish to. This
> doesn't affect any project's choice to use one version over another
> for the parent POM, or to use one plugin version that might be
> declared with a managed version in the parent POM over another.
>
> The only thing this does is make it slightly easier to override stuff
> defined in the parent POM (and even more slightly easier to maintain
> the parent POM itself, because diffs will be slightly smaller when
> updating any default versions).
>
> So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
> issue that you need fixed for your project, you don't have to wait for
> a new release of MPOM... you can easily just do:
>
> ```xml
> <properties>
> <!-- naming convention still being discussed, but this is an example
> -->
> <version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
> </properties>
> ```
>
> Previously, you would have had to do:
>
> ```xml
> <build>
> <pluginManagement>
> <plugins>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-compiler-plugin</artifactId>
> <version>3.11.1</version>
> </plugins>
> </pluginManagement>
> </build>
> ```
>
> You can still use the latter, if you really want to.
>
> So, I don't understand Allen's -1 on the basis that some people need
> to use specific versions of the parent POM, or even specific versions
> of specific plugins. The proposed change only makes that easier... and
> only if they want to take the easier path, which is still optional.
> Whether or not some plugin versions cause problems or not for users is
> irrelevant.... this only makes it easier for users to choose the
> version they need. Otherwise, it has no impact to them whatsoever.
>
> On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de>
> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> > >
> > >
> > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <
> s.jaranowski@gmail.com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I want to introduce properties to define versions of plugins.
> > >> I have prepared PR [1] and we have a discussion about properties
> schema for
> > >> such purposes.
> > >>
> > >> Because AFS Maven parent is used by other ASF projects, and such
> changes
> > >> can be difficult to change in the next release, I want to know other
> > >> opinions.
> > >
> > > -1
> > >
> > > Some projects are stuck on old versions of the pom because newer ones
> introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on
> v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
> >
> > Kind regards
> > Karl Heinz Marbaise
> >
> >
> >
> > > So no, the parent pom needs to define less, not more.
> > >
> > > [I’m almost to the point of just forking the thing and removing bits
> because it is so wildly unreliable.]
> > >
> >
> >
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
It doesn't matter that some projects are stuck on old versions, or
their reasons why. That's not a valid technical reason to -1 the
proposed changes, as it has nothing to do with the proposed changes.
The proposal was to use properties in the Apache parent POM (MPOM) to
make it easier for projects that use the parent POM to override the
versions of the plugins that are defined in it, if they wish to. This
doesn't affect any project's choice to use one version over another
for the parent POM, or to use one plugin version that might be
declared with a managed version in the parent POM over another.
The only thing this does is make it slightly easier to override stuff
defined in the parent POM (and even more slightly easier to maintain
the parent POM itself, because diffs will be slightly smaller when
updating any default versions).
So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
issue that you need fixed for your project, you don't have to wait for
a new release of MPOM... you can easily just do:
```xml
<properties>
<!-- naming convention still being discussed, but this is an example -->
<version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
</properties>
```
Previously, you would have had to do:
```xml
<build>
<pluginManagement>
<plugins>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.1</version>
</plugins>
</pluginManagement>
</build>
```
You can still use the latter, if you really want to.
So, I don't understand Allen's -1 on the basis that some people need
to use specific versions of the parent POM, or even specific versions
of specific plugins. The proposed change only makes that easier... and
only if they want to take the easier path, which is still optional.
Whether or not some plugin versions cause problems or not for users is
irrelevant.... this only makes it easier for users to choose the
version they need. Otherwise, it has no impact to them whatsoever.
On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi,
> On 07.06.23 19:23, Allen Wittenauer wrote:
> >
> >
> >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I want to introduce properties to define versions of plugins.
> >> I have prepared PR [1] and we have a discussion about properties schema for
> >> such purposes.
> >>
> >> Because AFS Maven parent is used by other ASF projects, and such changes
> >> can be difficult to change in the next release, I want to know other
> >> opinions.
> >
> > -1
> >
> > Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
>
> The issue is related to a non Apache API (build-api related to Eclipse)
> abandoned (12 years old+) ...
> And why does a Eclipse related bugs stops you to use that in builds?
>
> Which plugins are we talking exactly? Which kind of bugs have occurred?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> > So no, the parent pom needs to define less, not more.
> >
> > [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
> >
>
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Herve Boutemy <hb...@apache.org>.
bugs will always happen: that's why introducing these properties make it easier for users to override proposed default version
And on MASSEMBLY-941 specifically, this has been fixed in 3.5.0 (sorry, I had one use case in mind and did not see another use case I broke) and is included in the ASF 30 parent POM to be released soon
But the key aspect here is not one specific issue, it's about making it easier to tweak plugins versions when using ASF parent POM whatever issue that will arise
Regards,
Hervé
On 2023/06/08 00:26:10 Allen Wittenauer wrote:
>
>
> > On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> >>
> >>
> >>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I want to introduce properties to define versions of plugins.
> >>> I have prepared PR [1] and we have a discussion about properties schema for
> >>> such purposes.
> >>>
> >>> Because AFS Maven parent is used by other ASF projects, and such changes
> >>> can be difficult to change in the next release, I want to know other
> >>> opinions.
> >>
> >> -1
> >>
> >> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
>
> Woops, I meant MASSEMBLY-941, which left a trail of dead in its wake, all linked to in the ticket.
>
> I know I hit a bug in the latest maven pom where it (i’m guessing assembly again) tries to resolve relative symlinks and makes them absolute which then in turn blows up with the latest pom. I don’t have time to track it down, so I’ll likely just stick with an ancient version of the Apache pom. I just don’t have time to debug this stuff. Even though we only release this project maybe twice a year, every year it is “can we udpate apache pom? nope.” so at least I know I’ll likely just stop even attempting to do it.
>
>
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 7, 2023, at 9:36 PM, Christopher <ct...@apache.org> wrote:
>
> I think your concern about the risks of updating plugin versions is
> valid, but I don't think it has anything to do with how those plugin
> versions are expressed in the parent POM. If anything, using
> properties to express these versions would make it easier for you to
> update the parent POM, but hold back specific plugins when those
> versions cause problems for you. You could also continue doing what
> you're doing now and not update the parent POM. That's perfectly
> valid. I just wonder, if you're going to do that, why care about how
> versions are expressed as properties in newer versions of the parent
> POM, enough to offer a -1 at the idea, if you're not even interested
> in using those newer versions of the parent POM?
I was under the impression that a bunch of _new_ entries were suddenly going to happen with this change. I’m a big fan of less is more in my build tools.
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 7, 2023, at 9:36 PM, Christopher <ct...@apache.org> wrote:
>
> I think your concern about the risks of updating plugin versions is
> valid, but I don't think it has anything to do with how those plugin
> versions are expressed in the parent POM. If anything, using
> properties to express these versions would make it easier for you to
> update the parent POM, but hold back specific plugins when those
> versions cause problems for you. You could also continue doing what
> you're doing now and not update the parent POM. That's perfectly
> valid. I just wonder, if you're going to do that, why care about how
> versions are expressed as properties in newer versions of the parent
> POM, enough to offer a -1 at the idea, if you're not even interested
> in using those newer versions of the parent POM?
I was under the impression that a bunch of _new_ entries were suddenly going to happen with this change. I’m a big fan of less is more in my build tools.
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
On Wed, Jun 7, 2023 at 8:26 PM Allen Wittenauer <aw...@apache.org> wrote:
>
>
>
> > On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> >>
> >>
> >>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I want to introduce properties to define versions of plugins.
> >>> I have prepared PR [1] and we have a discussion about properties schema for
> >>> such purposes.
> >>>
> >>> Because AFS Maven parent is used by other ASF projects, and such changes
> >>> can be difficult to change in the next release, I want to know other
> >>> opinions.
> >>
> >> -1
> >>
> >> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
>
> Woops, I meant MASSEMBLY-941, which left a trail of dead in its wake, all linked to in the ticket.
>
> I know I hit a bug in the latest maven pom where it (i’m guessing assembly again) tries to resolve relative symlinks and makes them absolute which then in turn blows up with the latest pom. I don’t have time to track it down, so I’ll likely just stick with an ancient version of the Apache pom. I just don’t have time to debug this stuff. Even though we only release this project maybe twice a year, every year it is “can we udpate apache pom? nope.” so at least I know I’ll likely just stop even attempting to do it.
>
>
I think your concern about the risks of updating plugin versions is
valid, but I don't think it has anything to do with how those plugin
versions are expressed in the parent POM. If anything, using
properties to express these versions would make it easier for you to
update the parent POM, but hold back specific plugins when those
versions cause problems for you. You could also continue doing what
you're doing now and not update the parent POM. That's perfectly
valid. I just wonder, if you're going to do that, why care about how
versions are expressed as properties in newer versions of the parent
POM, enough to offer a -1 at the idea, if you're not even interested
in using those newer versions of the parent POM?
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
On Wed, Jun 7, 2023 at 8:26 PM Allen Wittenauer <aw...@apache.org> wrote:
>
>
>
> > On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
> >
> > Hi,
> > On 07.06.23 19:23, Allen Wittenauer wrote:
> >>
> >>
> >>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I want to introduce properties to define versions of plugins.
> >>> I have prepared PR [1] and we have a discussion about properties schema for
> >>> such purposes.
> >>>
> >>> Because AFS Maven parent is used by other ASF projects, and such changes
> >>> can be difficult to change in the next release, I want to know other
> >>> opinions.
> >>
> >> -1
> >>
> >> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
> >
> > The issue is related to a non Apache API (build-api related to Eclipse)
> > abandoned (12 years old+) ...
> > And why does a Eclipse related bugs stops you to use that in builds?
> >
> > Which plugins are we talking exactly? Which kind of bugs have occurred?
>
> Woops, I meant MASSEMBLY-941, which left a trail of dead in its wake, all linked to in the ticket.
>
> I know I hit a bug in the latest maven pom where it (i’m guessing assembly again) tries to resolve relative symlinks and makes them absolute which then in turn blows up with the latest pom. I don’t have time to track it down, so I’ll likely just stick with an ancient version of the Apache pom. I just don’t have time to debug this stuff. Even though we only release this project maybe twice a year, every year it is “can we udpate apache pom? nope.” so at least I know I’ll likely just stop even attempting to do it.
>
>
I think your concern about the risks of updating plugin versions is
valid, but I don't think it has anything to do with how those plugin
versions are expressed in the parent POM. If anything, using
properties to express these versions would make it easier for you to
update the parent POM, but hold back specific plugins when those
versions cause problems for you. You could also continue doing what
you're doing now and not update the parent POM. That's perfectly
valid. I just wonder, if you're going to do that, why care about how
versions are expressed as properties in newer versions of the parent
POM, enough to offer a -1 at the idea, if you're not even interested
in using those newer versions of the parent POM?
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi,
> On 07.06.23 19:23, Allen Wittenauer wrote:
>>
>>
>>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I want to introduce properties to define versions of plugins.
>>> I have prepared PR [1] and we have a discussion about properties schema for
>>> such purposes.
>>>
>>> Because AFS Maven parent is used by other ASF projects, and such changes
>>> can be difficult to change in the next release, I want to know other
>>> opinions.
>>
>> -1
>>
>> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
>
> The issue is related to a non Apache API (build-api related to Eclipse)
> abandoned (12 years old+) ...
> And why does a Eclipse related bugs stops you to use that in builds?
>
> Which plugins are we talking exactly? Which kind of bugs have occurred?
Woops, I meant MASSEMBLY-941, which left a trail of dead in its wake, all linked to in the ticket.
I know I hit a bug in the latest maven pom where it (i’m guessing assembly again) tries to resolve relative symlinks and makes them absolute which then in turn blows up with the latest pom. I don’t have time to track it down, so I’ll likely just stick with an ancient version of the Apache pom. I just don’t have time to debug this stuff. Even though we only release this project maybe twice a year, every year it is “can we udpate apache pom? nope.” so at least I know I’ll likely just stop even attempting to do it.
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Christopher <ct...@apache.org>.
It doesn't matter that some projects are stuck on old versions, or
their reasons why. That's not a valid technical reason to -1 the
proposed changes, as it has nothing to do with the proposed changes.
The proposal was to use properties in the Apache parent POM (MPOM) to
make it easier for projects that use the parent POM to override the
versions of the plugins that are defined in it, if they wish to. This
doesn't affect any project's choice to use one version over another
for the parent POM, or to use one plugin version that might be
declared with a managed version in the parent POM over another.
The only thing this does is make it slightly easier to override stuff
defined in the parent POM (and even more slightly easier to maintain
the parent POM itself, because diffs will be slightly smaller when
updating any default versions).
So, if MPOM ships with maven-compiler-plugin 3.11.0, but that has an
issue that you need fixed for your project, you don't have to wait for
a new release of MPOM... you can easily just do:
```xml
<properties>
<!-- naming convention still being discussed, but this is an example -->
<version.maven-compiler-plugin>3.11.1</version.maven-compiler-plugin>
</properties>
```
Previously, you would have had to do:
```xml
<build>
<pluginManagement>
<plugins>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.11.1</version>
</plugins>
</pluginManagement>
</build>
```
You can still use the latter, if you really want to.
So, I don't understand Allen's -1 on the basis that some people need
to use specific versions of the parent POM, or even specific versions
of specific plugins. The proposed change only makes that easier... and
only if they want to take the easier path, which is still optional.
Whether or not some plugin versions cause problems or not for users is
irrelevant.... this only makes it easier for users to choose the
version they need. Otherwise, it has no impact to them whatsoever.
On Wed, Jun 7, 2023 at 2:47 PM Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi,
> On 07.06.23 19:23, Allen Wittenauer wrote:
> >
> >
> >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
> >>
> >> Hi,
> >>
> >> I want to introduce properties to define versions of plugins.
> >> I have prepared PR [1] and we have a discussion about properties schema for
> >> such purposes.
> >>
> >> Because AFS Maven parent is used by other ASF projects, and such changes
> >> can be difficult to change in the next release, I want to know other
> >> opinions.
> >
> > -1
> >
> > Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
>
> The issue is related to a non Apache API (build-api related to Eclipse)
> abandoned (12 years old+) ...
> And why does a Eclipse related bugs stops you to use that in builds?
>
> Which plugins are we talking exactly? Which kind of bugs have occurred?
>
> Kind regards
> Karl Heinz Marbaise
>
>
>
> > So no, the parent pom needs to define less, not more.
> >
> > [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
> >
>
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise <kh...@gmx.de> wrote:
>
> Hi,
> On 07.06.23 19:23, Allen Wittenauer wrote:
>>
>>
>>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I want to introduce properties to define versions of plugins.
>>> I have prepared PR [1] and we have a discussion about properties schema for
>>> such purposes.
>>>
>>> Because AFS Maven parent is used by other ASF projects, and such changes
>>> can be difficult to change in the next release, I want to know other
>>> opinions.
>>
>> -1
>>
>> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
>
> The issue is related to a non Apache API (build-api related to Eclipse)
> abandoned (12 years old+) ...
> And why does a Eclipse related bugs stops you to use that in builds?
>
> Which plugins are we talking exactly? Which kind of bugs have occurred?
Woops, I meant MASSEMBLY-941, which left a trail of dead in its wake, all linked to in the ticket.
I know I hit a bug in the latest maven pom where it (i’m guessing assembly again) tries to resolve relative symlinks and makes them absolute which then in turn blows up with the latest pom. I don’t have time to track it down, so I’ll likely just stick with an ancient version of the Apache pom. I just don’t have time to debug this stuff. Even though we only release this project maybe twice a year, every year it is “can we udpate apache pom? nope.” so at least I know I’ll likely just stop even attempting to do it.
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 07.06.23 19:23, Allen Wittenauer wrote:
>
>
>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>>
>> Hi,
>>
>> I want to introduce properties to define versions of plugins.
>> I have prepared PR [1] and we have a discussion about properties schema for
>> such purposes.
>>
>> Because AFS Maven parent is used by other ASF projects, and such changes
>> can be difficult to change in the next release, I want to know other
>> opinions.
>
> -1
>
> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
The issue is related to a non Apache API (build-api related to Eclipse)
abandoned (12 years old+) ...
And why does a Eclipse related bugs stops you to use that in builds?
Which plugins are we talking exactly? Which kind of bugs have occurred?
Kind regards
Karl Heinz Marbaise
> So no, the parent pom needs to define less, not more.
>
> [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
On 07.06.23 19:23, Allen Wittenauer wrote:
>
>
>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>>
>> Hi,
>>
>> I want to introduce properties to define versions of plugins.
>> I have prepared PR [1] and we have a discussion about properties schema for
>> such purposes.
>>
>> Because AFS Maven parent is used by other ASF projects, and such changes
>> can be difficult to change in the next release, I want to know other
>> opinions.
>
> -1
>
> Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
The issue is related to a non Apache API (build-api related to Eclipse)
abandoned (12 years old+) ...
And why does a Eclipse related bugs stops you to use that in builds?
Which plugins are we talking exactly? Which kind of bugs have occurred?
Kind regards
Karl Heinz Marbaise
> So no, the parent pom needs to define less, not more.
>
> [I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>
> Hi,
>
> I want to introduce properties to define versions of plugins.
> I have prepared PR [1] and we have a discussion about properties schema for
> such purposes.
>
> Because AFS Maven parent is used by other ASF projects, and such changes
> can be difficult to change in the next release, I want to know other
> opinions.
-1
Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
So no, the parent pom needs to define less, not more.
[I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi
Currently we have two propositions:
1. <artifactId in camelCase>Versions - like mavenCleanPluginVersion [1]
2. version.<artifactId> - like version.maven-clean-plugin [2]
As I see from comments on PR more people is for option 2
[1] https://github.com/apache/maven-apache-parent/pull/155
[2] https://github.com/apache/maven-apache-parent/pull/158
wt., 6 cze 2023 o 00:28 Slawomir Jaranowski <s....@gmail.com>
napisał(a):
> Hi,
>
> I want to introduce properties to define versions of plugins.
> I have prepared PR [1] and we have a discussion about properties schema
> for such purposes.
>
> Because AFS Maven parent is used by other ASF projects, and such changes
> can be difficult to change in the next release, I want to know other
> opinions.
>
> [1] https://github.com/apache/maven-apache-parent/pull/155
>
>
> --
> Sławomir Jaranowski
>
--
Sławomir Jaranowski
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Herve Boutemy <hb...@apache.org>.
yes, it has been considered
and the short answer is: BOM POM cannot work for this use case
longer answer for those who want to dive:
1. current BOM POM is about dependencyManagement: here we would need pluginManagement
adding pluginManagement import idea has been opened for a long time https://issues.apache.org/jira/browse/MNG-5588
and I did a PoC some time ago and got to the conclusion that
2. if we had pluginManagement POM import, if would not give us what people want
if we used such pluginManagement POM import, it would be exactly like defining version in parent POM without properties: to override, end user would require to write pluginManagement entries in XML = too many lines of XML
that's why people love properties for plugins versions: it's only one line
Regards,
Hervé
On 2023/06/06 06:57:59 Vladimir Sitnikov wrote:
> > I want to introduce properties to define versions of plugins.
>
> Have you considered publishing a BOM with versions instead?
> Then the ones who need the versions could import the BOM.
>
> I believe the task of "sharing a set of versions among projects" should
> better be
> approached with "dependencyManagement" in pom.xml
> rather than inventing yet another convention for property names.
>
> Vladimir
>
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Vladimir Sitnikov <si...@gmail.com>.
> I want to introduce properties to define versions of plugins.
Have you considered publishing a BOM with versions instead?
Then the ones who need the versions could import the BOM.
I believe the task of "sharing a set of versions among projects" should
better be
approached with "dependencyManagement" in pom.xml
rather than inventing yet another convention for property names.
Vladimir
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Slawomir Jaranowski <s....@gmail.com>.
Hi
Currently we have two propositions:
1. <artifactId in camelCase>Versions - like mavenCleanPluginVersion [1]
2. version.<artifactId> - like version.maven-clean-plugin [2]
As I see from comments on PR more people is for option 2
[1] https://github.com/apache/maven-apache-parent/pull/155
[2] https://github.com/apache/maven-apache-parent/pull/158
wt., 6 cze 2023 o 00:28 Slawomir Jaranowski <s....@gmail.com>
napisał(a):
> Hi,
>
> I want to introduce properties to define versions of plugins.
> I have prepared PR [1] and we have a discussion about properties schema
> for such purposes.
>
> Because AFS Maven parent is used by other ASF projects, and such changes
> can be difficult to change in the next release, I want to know other
> opinions.
>
> [1] https://github.com/apache/maven-apache-parent/pull/155
>
>
> --
> Sławomir Jaranowski
>
--
Sławomir Jaranowski
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Allen Wittenauer <aw...@apache.org>.
> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski <s....@gmail.com> wrote:
>
> Hi,
>
> I want to introduce properties to define versions of plugins.
> I have prepared PR [1] and we have a discussion about properties schema for
> such purposes.
>
> Because AFS Maven parent is used by other ASF projects, and such changes
> can be difficult to change in the next release, I want to know other
> opinions.
-1
Some projects are stuck on old versions of the pom because newer ones introduce plugins with bugs. e.g., MASSEMBLY-942 stopped some projects on v21 for a very long time.
So no, the parent pom needs to define less, not more.
[I’m almost to the point of just forking the thing and removing bits because it is so wildly unreliable.]
Re: ASF Maven parent pom and use properties to define the versions of plugins
Posted by Vladimir Sitnikov <si...@gmail.com>.
> I want to introduce properties to define versions of plugins.
Have you considered publishing a BOM with versions instead?
Then the ones who need the versions could import the BOM.
I believe the task of "sharing a set of versions among projects" should
better be
approached with "dependencyManagement" in pom.xml
rather than inventing yet another convention for property names.
Vladimir