Externalize default lifecycle plugin versions to POM properties

[gnodet]

Move the 13 hardcoded plugin version constants from Java source into POM properties in impl/maven-core/pom.xml. The values are filtered at build time into plugin-versions.properties and loaded at runtime by a new PluginVersions utility class.

This makes the default lifecycle plugin versions visible to dependency-update bots (Dependabot, Renovate) that scan POM files for version properties, enabling automated version bump PRs.

Changes:

• impl/maven-core/pom.xml — Add <properties> section with version.maven-<name>-plugin entries for all 13 default plugins
• plugin-versions.properties — New resource file with ${...} placeholders, filtered at build time
• PluginVersions.java — New utility class that loads versions from the properties file and exposes them as constants
• AbstractLifecycleMappingProvider.java — Replace hardcoded version strings with PluginVersions.* constants
• DefaultLifecycleRegistry.java — Replace hardcoded clean/site plugin versions with PluginVersions.* constants

No behavioral change: all version values are identical to the previous hardcoded constants.

Follow-up to the discussion in #13076 about automating plugin version bumps.

[gnodet]

Three issues to fix before merge: a silent-failure mode when resource filtering is not applied, a public API surface that doesn't need to be public, and a milestone mismatch.

This review was generated by an AI agent, Hermès, on behalf of @gnodet.

[gnodet]

⚠️ Silent failure: unfiltered placeholder survives null check

VERSIONS.getProperty(key) returns "${version.maven-clean-plugin}" (not null) when resource filtering is skipped — e.g. when the class is loaded from an IDE or test classpath built without the Maven resources plugin running. The null guard does not catch this: the constant is set to a literal ${…} string, Maven silently tries to resolve a plugin at that version, and the user gets a cryptic "not found in repository" error at build time with no clue that the properties file was never filtered.

Add a format guard that fails fast at class-init time:

Suggested change

	public static String version(String pluginArtifactId) {
	String key = pluginArtifactId + ".version";
	String version = VERSIONS.getProperty(key);
	if (version == null) {
	throw new IllegalArgumentException("No default version defined for " + pluginArtifactId + "; add " + key
	+ " to plugin-versions.properties");
	}
	return version;
	}
	public static String version(String pluginArtifactId) {
	String key = pluginArtifactId + ".version";
	String version = VERSIONS.getProperty(key);
	if (version == null) {
	throw new IllegalArgumentException("No default version defined for " + pluginArtifactId + "; add " + key
	+ " to plugin-versions.properties");
	}
	if (version.startsWith("${")) {
	throw new ExceptionInInitializerError(
	"plugin-versions.properties was not filtered at build time; "
	+ key + " still contains placeholder: " + version);
	}
	return version;
	}

[gnodet]

🔸 Unnecessary public API surface

version(String) is public but its only callers are the 13 constants in this same class (all called during class initialisation). Once the constants exist, nothing outside this class needs to call version() at runtime — the public constants are the intended API. Exposing the method invites callers to store the result in their own fields, bypassing future caching or validation improvements.

Make it private:

Suggested change

	public static String version(String pluginArtifactId) {
	private static String version(String pluginArtifactId) {

If external code genuinely needs to look up an arbitrary plugin version, that can be added as a separate, explicitly-documented public method later (with a stronger contract).

[gnodet]

💡 No test for the loading mechanism

The static initialiser, the filtering round-trip, and the null/placeholder guards are the critical path of this new class, yet there is no unit test. A minimal test verifying that every constant is non-null and does not look like an unfiltered placeholder (!CLEAN.startsWith("${")) would catch the filtering-skipped scenario and guard against future regressions (e.g. a new constant added to the class but forgotten in the properties file).

Example:

@Test
void pluginVersionsAreResolved() {
    // Verify all constants are loaded and not unfiltered placeholders
    for (Field f : PluginVersions.class.getFields()) {
        if (f.getType() == String.class) {
            String value = (String) f.get(null);
            assertNotNull(value, f.getName() + " is null");
            assertFalse(value.startsWith("${"), f.getName() + " is unfiltered: " + value);
        }
    }
}

[gnodet]

Milestone mismatch: the PR targets master (4.1.0-SNAPSHOT) but is assigned to milestone 4.0.0-rc-7 (which tracks the maven-4.0.x branch). The @since 4.1.0 Javadoc in PluginVersions confirms this is intended for 4.1.0. Please update the milestone to 4.x or 4.1.0.

This comment was generated by an AI agent, Hermès, on behalf of @gnodet.

[elharo]

Maybe deprecate these fields, or just remove them if this is all new in 4.0.lx