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.
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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?
Comment From: 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.
Comment From: 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.
Comment From: wilkinsona
Things would get complicated for users if they overrode the version of the NBT plugin. They'd then get a default version of the metadata that's unexpected.
Taking a small step back from the metadata version, I'm not even sure that we should be managing the version of the NBT plugin. We don't do so for Gradle and doing so for Maven may create more problems than it solves.
Both the NBT plugin and the metadata are evolving quite rapidly at the moment. If we manage the version in Boot, there becomes an expectation that the version will only be updated in line with our usual maintenance policy – we'd only pick up maintenance releases of the metadata and the build plugin in maintenance releases of Boot. I'm not sure that the build plugin is ready for that, even less so the metadata. We may be better avoiding this problem by not managing the versions at all but this will come at the code of making application poms more verbose. It's unfortunate that Maven doesn't allow us to provide some default configuration for a plugin without having to specify a version.