[MPH-182] mvn help:evaluate does not evaluate java.version correctly

[jira-importer]

Matt smith opened MPH-182 and commented

Steps to reproduce:

1. Create a Java project with Maven.
2. Set a new property called java.version and set the value to a different value from your installed JDK.
3. Run mvn help:evaluate and use the expression ${java.version}
4. The Java version that will be output will be your JDK version, not the property value.

Ideal behaviour:

• Value that is output is the value that is within the java.version property.

Workaround:

• Set another property (e.g. something) to the value ${java.version}
• Run mvn help:evaluate and use the expression ${something}
• The correct property value will be output.

---

Attachments:

• Screenshot 2021-10-08 at 11.19.07.png (13.05 kB)
• Screenshot 2021-10-08 at 11.19.38.png (33.13 kB)

2 votes, 3 watchers

[jira-importer]

Michael Osipov commented

I think this is rooted in the expression evaluator in Maven Core. It goes through a stacked design of sources: org.apache.maven.project.interpolation.AbstractStringBasedModelInterpolator.createValueSources(Model, File, ProjectBuilderConfiguration)

[jira-importer]

Miroslav Zaťko commented

in my case, on ubuntu, plugin shows "complete" value of java internal property "java.version" like "17.0.8.1" resp. "11.0.20.1" resp. "1.8.0_382" not just "17" as on screenshot

[elharo]

I'm not sure whether this is a bug or WAI. The question is about precedence of Java system properties vs POM properties. However, if it is a bug (and you can certainly argue that it is) the bug is not in the help plugin but rather in maven core. More deets from Gemini:

The issue of help:evaluate not returning user-defined POM properties when they shadow Java system properties (like java.version) is fundamentally a limitation in Maven Core, rather than a bug isolated to the maven-help-plugin.

However, any fix would likely need to be implemented within Maven Core's interpolation and expression evaluation components, not the plugin itself, unless the plugin chooses to implement a non-standard workaround.

Here is the technical reasoning behind where the fix belongs:

1. The Design of Maven Core's Expression Evaluator

The maven-help-plugin does not contain its own property resolution logic for help:evaluate. It delegates the evaluation of the expression to Maven Core's PluginParameterExpressionEvaluator (and deeper into the AbstractStringBasedModelInterpolator).

Maven Core's property resolution is explicitly designed with a strict precedence hierarchy:

1. System properties (e.g., -D command-line arguments and JVM built-in properties like java.version, os.name, user.home)
2. Profile properties (from settings.xml or active POM profiles)
3. Project properties (from the POM <properties> section)

Because java.version is a built-in JVM system property, Maven Core's evaluator hits layer 1, finds the JVM's runtime version, and stops looking. It never reaches layer 3 where the user's POM property is defined.

2. Fixing it in the Plugin creates inconsistencies

If a developer implemented a custom override inside EvaluateMojo.java (as suggested in the previous response) to force the plugin to read from POM <properties> first, it would create a dangerous inconsistency across the Maven ecosystem:

• mvn help:evaluate -Dexpression=java.version would output the POM value (e.g., 11).
• However, if another plugin (like the maven-compiler-plugin or maven-resources-plugin) encountered ${java.version} in its configuration, Maven Core would still inject the JVM system property (e.g., 17.0.8).

A diagnostic tool (help:evaluate) must accurately report how the core engine resolves values. If the plugin uses a different resolution strategy than the core engine, it ceases to be an accurate diagnostic tool.

3. The Core Dilemma (MNG-7833 / MNG-7914 context)

Changing the precedence order in Maven Core so that POM properties override System properties would be a massive, breaking change to the Maven ecosystem. Builds worldwide rely on the ability to override POM properties via the command line (e.g., mvn clean install -Dmy.property=value). Because command-line -D arguments are injected as System Properties, dropping System Properties below POM properties in precedence would disable command-line overrides entirely.

Conclusion

This should not be "fixed" in the help-plugin.

The most appropriate resolution is to treat this as an educational issue regarding Maven's design: Users should not use reserved JVM system property keys as custom POM property names.

If the Apache Maven team were to address this, the most viable path would be adding a warning mechanism inside Maven Core's model builder that emits a build warning when a user declares a property in their POM that shadows a known read-only JVM system property.