[MNG-8765] Pre-interpolate plugin configuration before type conversion

[gnodet]

Summary

• Pre-interpolates PlexusConfiguration values using the expression evaluator in DefaultMavenPluginManager before passing them to the ComponentConfigurator, ensuring ${...} property references are fully resolved before type converters (like UriConverter) process the values
• Fixes the case where properties set dynamically at runtime (e.g., by Groovy/GMaven scripts via project.properties.setProperty()) are not available during model interpolation and reach type converters unresolved, causing URISyntaxException for URI-typed parameters
• Adds integration tests covering URI property interpolation with POM properties, inherited parent properties, and CLI-passed properties

Regression found in CloudStack (gnodet/maven4-testing#34733) where a URI parameter with ${cs.version} set by a Groovy script at runtime caused URISyntaxException.

Test plan

• Unit tests pass (580 tests in impl/maven-core)
• New IT MavenITmng8765UriPropertyInterpolationTest passes:
  • POM-defined properties in URI parameters (parent + child modules)
  • CLI-passed properties (-D) in URI parameters
• Existing plugin config ITs pass (MNG-3827, MNG-3864, MNG-0828, IT-0009)
• Full CI build

🤖 Generated with Claude Code

[gnodet]

The pre-interpolation approach is sound in principle, but the implementation has a fundamental issue that renders the fix ineffective:

1. Interpolated values are silently discarded (high severity)

interpolateConfiguration stores resolved values in child XmlPlexusConfiguration wrappers obtained via getChildren(), but both the Plexus ObjectWithFieldsConverter and Maven's EnhancedConfigurationConverter access children via getChild(int), which creates new wrappers from the parent's unmodified immutable XmlNode tree — all interpolated values are lost.

Trace:

• getChildren() populates a childrenCache with wrappers
• setValue() replaces the wrapper's internal xmlNode but does NOT update the parent's xmlNode.children() (XmlNode is immutable)
• getChild(int) does NOT use the cache — it creates a fresh wrapper from xmlNode.children().get(i), which still holds the original uninterpolated child

Suggested approach: Reconstruct the XmlNode tree bottom-up with interpolated values and wrap it in a fresh XmlPlexusConfiguration, rather than mutating transient wrapper objects.

2. Tests don't cover the actual failure scenario (high severity)

The tests use POM-defined properties (test.version=1.2.3) and CLI properties (-Dcli.version=2.0.0), both of which are already resolved during model interpolation — before interpolateConfiguration runs. The tests pass with or without the fix. The actual MNG-8765 scenario (properties set dynamically at runtime via project.properties.setProperty() by Groovy/GMaven scripts) is not tested.

3. Fix only in loadV3Mojo (medium severity)

The interpolateConfiguration call is only added to loadV3Mojo. loadV4Mojo has the same pomConfiguration → populateMojoExecutionFields flow but no pre-interpolation, leaving V4 mojos with URI-typed parameters unprotected.

4. Javadoc inaccuracy (low severity)

The Javadoc says @return a new PlexusConfiguration but the method returns the same object mutated in place.

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

Claude Code on behalf of gnodet