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 <ctubb...@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 <khmarba...@gmx.de> > 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.] > > > > > > > >
