Update Maven plugin management to expose a configuration property for the Native Metadata Repository version

[snicoll]

As discussed with @odrotbohm, overriding the version of the metadata repository requires to redefine the plugin coordinates. There's an interest that Spring Boot has an opinion about this. The NBT plugin hardcodes the version to use and it can lag with an older version of the plugin.

At the moment the version offered is 0.1.0 while 0.1.2 is available.

[snicoll]

We've discussed and we can't really do that as setting a property for this means we need to harmonize the value that our Gradle plugin would use. That makes the whole thing weird as users are applying the plugin themselves and shouldn't expect the version that it brings to be overridden.

[odrotbohm]

Can you elaborate a bit? Isn't the need to harmonize given for every property that Boot exposes? It still does so for all dependency versions. I am afraid we let users run into a situation in which they can upgrade to a new dependency version of a library using a property, but cannot move to a newer version of the metadata repository (which might be needed as the new version of the dependency requires updated metadata) that would make that library update work on native without having to redeclare the entire native plugin.

I don't get the "applying the plugin themselves" part. Do you mean declaring it? The starter parent brings in the plugin, whose build goal is triggered through a default lifecycle mapping. I can tweak the Java version to be used for the Maven Compile Plugin via a local property definition, too, so why shouldn't I be able to tweak the metadata repository version option that way?

[snicoll]

I think you missed "we need to harmonize the value that our Gradle plugin would use". While I agree it would be an interesting feature, we need to make sure it is in par with Gradle and we unfortunately can't make that happen. The lack of consistency is key in declining this issue.

[odrotbohm]

It might sound stupid, but I still don't understand why this is a dealbreaker. Because the default value would need to be defined in both the Maven parent POM and as some value within our Gradle plugin? Is the concern that, to upgrade that default value, it would have to be changed in both places?

[snicoll]

Because the default value would need to be defined in both the Maven parent POM and as some value within our Gradle plugin?

The plugin sets a version by default and we don't want to override it. If a user applies version X.Y.Z of the plugin, they should get a certain version of the metadata OOTB and upgrading the plugin should upgrading the version of the metadata if they haven't expressed an opinion. This makes the whole thing confusing if we expose a property. In retrospect, it's not even related to Gradle at all as overriding the version of the plugin in Maven should give you that as well.

[odrotbohm]

Wouldn't that just mean that you'd have to update the default version the property would have alongside the update of the plugin version you declare? If that was done in sync, developers would still get the plugin's default by default (thought the Boot property declared) but were able to override that version through a simple property.