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.]
> >
>
>

Reply via email to