Extract plugin version as variable so child pom can override if needed

[nhojpatrick]

Due to children supporting maven 3.0.0+ and java 1.6, 1.7, 1.8, 11 and 14+, it might be needed to upgrade a plugin to a newer version. Extracting current version into a property will allow downstream child pom's to override if needed.

[khmarbaise]

Putting the versions of plugins into a property is not the prerequisites to be able to overwrite in childs. If you like to override a plugin version you can simply do that via pluginManagement.

[nhojpatrick]

agree but doing something like ./mvnw clean verify -Dmaven-surefire-plugin.version=3.0.0-M4 is a lot easier, and less invasive for child projects. then just add the property if you want to keep that version, you might also want the exact same configuration or executions, just on a newer plugin version.

[andham]

Altering the build via cli parameters is an anti-pattern.

As Karl Heinz says, if you want to change the plugin version you can override that in the pluginMgmt section of your pom. The configuration is then inherited, but you can also override specific config options.

I'm a strong -1 to this PR.

[khmarbaise]

On thing more. Usually you have CI/CD pipelines configured which can't easily being change (or shouldn't based on the influences on other builds) and don't want to...but you can create a branch on which you can change the pom file in your branch ...If that is really necessary. If I have to upgrade/change plugins I simply do that in a branch...and check compatibility. If it works it will be merged into master. Later the parents will be changed with the same pattern...I never use the command line to overwrite plugin versions/dependency versions...

And yes I'm also -1 to this PR.

[nhojpatrick]

Okay I'll close... want me to raise a PR to revert the existing setup already using this anti-pattern?

Out of interest who's anti-pattern is this???

As I've been using maven since 2005 and wasn't aware it was an anti-pattern, so I've been advocating and implementing this style on now at least 75 projects (multi-module project counting as 1) with great success.

A few large 1+ million SLOC, could work with a newer version of surefire, but some sub modules had to use older versions for a range of reason and this was simple done with a property in that project.

@khmarbaise not sure what your talking about CI/CD being difficult to alter and commuting a alter pom to a different branch...

I've only used the command line to experiment with a new plugin or dependency, I would never alter CI/CD arguments to do this type experimentation. If I wanted CI/CD to try it out I would commit the property change.

Your style of bloating the child feels like an anti-pattern from my point of view.

A few others item's I was going to PR;

1. Upgrade to latest plugin
2. Upgrade to latest dependencies
3. Upgrade to maven wrapper
4. Switch to user projects like maven.compiler.source and maven.compiler.target instead of verbose plugin configuration.

Anyway you are the gate keepers...

[andham]

@nhojpatrick having version of plugins (and dependencies) is very common but I advocate that it isn't "The Maven Way". The reason is typically a developer mindset (where you define things that could change in variables/constants) but POMs are xml-based and IMO there is no benefit moving the version to a property. It's rather a bad thing as it makes it possible to override the version as a CLI property, which alters the build. But the build should ALWAYS be defined by the pom.

There are though a few cases IMO where it could be ok to move the version definition to a property. One such case is where the version should be synced in several case, such as m-surefire-p och m-failsafe-p. In that case it is very much possible to keep them in sync without a property, but real-world tests have shown that that si just theory in practice it tends to run out of sync.
If you have a look at the existing maven-javadoc-plugin.version property you'll see that it is used to keep the version in sync for two instances of that plugin. So it's a ok use case. But that doesn't mean that one should override the version from command-line. Ever!

Regardless of valid use case or not, we can't remove an existing property without verifying that it isn't used in any plugin inheriting. That could break builds otherwise. Also a reason for not using properties, it makes it possible for inheriting projects to use them even if it's not your intent. (But somethimes it is your intent.)

So I'd like to close this issue as "won't do", ok? But thanks for participating and I appreciate that some existing solutions are not always "The Maven Way", even not here.

[andham]

@nhojpatrick just to let you know, we've discussed "internally" and we'll most likely remove the existing version properties as they're not good (#91). We just need to verify that it doesn't break anythink. Thanks for bringing this to our attention!

[mfriedenhagen]

Hmm, then I have to rethink this as well, having all versions extracted as properties has worked for me (and our central company pom) for the last 10 years as well quite well.
I do this for dependencyManagement (springframework, slf4j etc.) and I do see this as an advantage to do this in a similar way for plugins.

[olamy]

I tend to agree is nice to use that and btw it's used a lot as it so easier to test new version

[mfriedenhagen]

Using version properties has the benefit that mojohause's versions plugin may be used for update automation as well.

[bmarwell]

@nhojpatrick could you be so kind as to rebase this PR? I think from reading the latest comments, we could merge it in.

[slachiewicz]

@bmarwell rebased, please check it