Skip to content

[mvnup] Add maven-war-plugin and maven-ear-plugin to plugin upgrade list - #12685

Open
gnodet wants to merge 1 commit into
apache:maven-4.0.xfrom
gnodet:mvnup-war-ear-plugin
Open

[mvnup] Add maven-war-plugin and maven-ear-plugin to plugin upgrade list#12685
gnodet wants to merge 1 commit into
apache:maven-4.0.xfrom
gnodet:mvnup-war-ear-plugin

Conversation

@gnodet

@gnodet gnodet commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Add maven-war-plugin (min 3.4.0) to the PLUGIN_UPGRADES list in PluginUpgradeStrategy
  • Add maven-ear-plugin (min 3.4.0) to the PLUGIN_UPGRADES list in PluginUpgradeStrategy

Both plugins use reflection on java.util.Properties internals (via XStream/plexus-archiver) in older versions, which is blocked by the JDK 17+ module system. Since Maven 4 requires JDK 17+, mvnup should upgrade these plugins to compatible versions.

Affected versions

Plugin Broken versions Fix version Root cause
maven-war-plugin < 3.3.2 3.4.0 XStream PropertiesConverter reflects on Properties.defaults field
maven-ear-plugin < 3.3.0 3.4.0 plexus-archiver uses reflection blocked by JDK 17+ modules

Context

Discovered during Maven 4 compatibility testing — projects like mina-vysper using maven-war-plugin:2.1.1 crash with:

java.lang.reflect.InaccessibleObjectException: Unable to make field protected volatile java.util.Properties java.util.Properties.defaults accessible

Running mvnup apply didn't fix this because maven-war-plugin wasn't in the upgrade list.

🤖 Generated with Claude Code

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two issues found — one is a bug:

1. Missing entries in getPluginUpgradesMap() (high severity)

The new maven-war-plugin and maven-ear-plugin entries are added to the PLUGIN_UPGRADES list (used by getPluginUpgradesAsMap() for effective model analysis) but not to getPluginUpgradesMap() (the manually-maintained HashMap used by upgradePluginsInDocument() for direct POM XML scanning). This means POMs that directly declare these plugins with explicit versions will not be upgraded through the document scanning path.

All 15 other plugins appear in both locations. This exact inconsistency class was previously identified and fixed in PR #12200.

Suggested fix — add to getPluginUpgradesMap() before the return upgrades; statement:

upgrades.put(
        DEFAULT_MAVEN_PLUGIN_GROUP_ID + ":maven-war-plugin",
        new PluginUpgradeInfo(DEFAULT_MAVEN_PLUGIN_GROUP_ID, "maven-war-plugin", "3.4.0"));
upgrades.put(
        DEFAULT_MAVEN_PLUGIN_GROUP_ID + ":maven-ear-plugin",
        new PluginUpgradeInfo(DEFAULT_MAVEN_PLUGIN_GROUP_ID, "maven-ear-plugin", "3.4.0"));

2. No tests for the new plugins (medium severity)

The existing test suite has individual test cases for surefire, failsafe, surefire-report, jaxb2, and quarkus. Following this established pattern, tests should verify that old versions of maven-war-plugin and maven-ear-plugin are upgraded to 3.4.0.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of gnodet

@gnodet gnodet added this to the 4.0.0-rc-7 milestone Aug 6, 2026
Both plugins use reflection on java.util.Properties internals (via
XStream/plexus-archiver) in older versions, which is blocked by the
JDK 17+ module system. Since Maven 4 requires JDK 17+, mvnup should
upgrade these plugins to compatible versions:

- maven-war-plugin: min 3.4.0 (fixed in 3.3.2+)
- maven-ear-plugin: min 3.4.0 (fixed in 3.3.0+)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@gnodet
gnodet force-pushed the mvnup-war-ear-plugin branch from 9d1de4d to 1e0eb72 Compare August 6, 2026 06:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant