help:evaluate returns wrong values for properties

[nerbb-techmatrix]

Affected version

at least 3.5.1, likely earlier versions too

Bug description

I am using maven v3.9.11

In my pom.xml I define something like

  <properties>
    <maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <plugin.id>foo-bar</plugin.id>
  </properties>

If I run

mvn org.apache.maven.plugins:maven-help-plugin:3.5.1:evaluate -Dexpression='plugin.id' -q -DforceStdout

I'd expect to get back foo-bar, instead I get back org.apache.maven.plugins:maven-help-plugin:3.5.1.

Using project.properties.plugin.id I get null object or invalid expression. I can however get all of the properties (including plugin.id) if I only use project.properties.

I have also tried with -Dartifact specified - the behavior didn't change.

This might be related to #310 and #336.

[Giovds]

I took a quick look into this. This will require a change in maven-core.

More specifically, the reason this happens (in Maven 3) is due to the evaluator used in the help-plugin. The PluginParameterExpressionEvaluator, which basically predefines a couple of checks, including startsWith("plugin"), before reaching the 'I don't know, let me look into user and system properties' step. We will see the same behaviour with any other predefined check such as project.*, mojo.*, settings.*.

Quickly looking into PluginParameterExpressionEvaluatorV4 (Maven 4 equivalent) this implementation will change a little bit.

I've written a test for both in maven-core. With the V4 evaluator this specific case will work, though I see the same behaviour for the kept prefixes. Besides that, the help-plugin is not yet Maven 4 compatible.

The question is: Should certain prefixes take precedence over properties?

I see a couple of options, that could be considered;

1. Wait for Maven 4 support
2. Change the implementation of Maven 3 plugin evaluator (I don't know the impact of this)
3. Not support this as some properties are 'reserved keywords'

Perhaps, in all cases this behaviour should be documented somewhere besides as Java Docs on the classes itself?