elharo commented on issue #310:
URL:
https://github.com/apache/maven-help-plugin/issues/310#issuecomment-5118211110
I'm not sure whether this is a bug or WAI. The question is ab out 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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
