Re: ASF Maven parent pom and use properties to define the versions of plugins
Hi Currently we have two propositions: 1. Versions - like mavenCleanPluginVersion [1] 2. version. - 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 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
> On Jun 7, 2023, at 9:36 PM, Christopher 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
On Wed, Jun 7, 2023 at 8:26 PM Allen Wittenauer wrote: > > > > > On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise wrote: > > > > Hi, > > On 07.06.23 19:23, Allen Wittenauer wrote: > >> > >> > >>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski > >>> 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
> On Jun 7, 2023, at 11:46 AM, Karl Heinz Marbaise wrote: > > Hi, > On 07.06.23 19:23, Allen Wittenauer wrote: >> >> >>> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski >>> 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
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 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 > > > 3.11.1 > > ``` > > Previously, you would have had to do: > > ```xml > > > > org.apache.maven.plugins > maven-compiler-plugin > 3.11.1 > > > > ``` > > 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 > wrote: > > > > Hi, > > On 07.06.23 19:23, Allen Wittenauer wrote: > > > > > > > > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski < > s.jaranow...@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
Forgive my typo there should be an extra layer of ` ... ` in the latter example. On Wed, Jun 7, 2023 at 6:41 PM Christopher 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 > > > 3.11.1 > > ``` > > Previously, you would have had to do: > > ```xml > > > > org.apache.maven.plugins > maven-compiler-plugin > 3.11.1 > > > > ``` > > 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 wrote: > > > > Hi, > > On 07.06.23 19:23, Allen Wittenauer wrote: > > > > > > > > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski > > >> 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
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 3.11.1 ``` Previously, you would have had to do: ```xml org.apache.maven.plugins maven-compiler-plugin 3.11.1 ``` 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 wrote: > > Hi, > On 07.06.23 19:23, Allen Wittenauer wrote: > > > > > >> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski > >> 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
Hi, On 07.06.23 19:23, Allen Wittenauer wrote: On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski 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
> On Jun 5, 2023, at 3:28 PM, Slawomir Jaranowski > 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
> 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
