Page History

...

The bar in the last example can be a special token: pom, env, or the legacy project which is deprecated
and means the same as pom.
In this case bar is called a prefix and the baz expression is evaluated against the project model
using reflection, so

${pom.version}

evalueates evaluates to the value of the <project><version> tag.

If the prefix is env, the expression evaluates to the value of System.getEnv( "baz" );

...

• determine the prefix: there is only a prefix if the expresssion starts with pom., project., or env.. In all other cases there is no prefix (it equals the empty string).
• if the prefix is project., log warning about project. prefix deprecation and replace it with the pom. prefix.
• if the expression has a prefix of pom., evaluate using reflection. If no result found, continue.
• if the expression has a prefix of env., evaluate using environment vars. If no result found, continue.
• check the context for the full expression, including prefix. If there was a key, but the value was null, don't touch this expression, but leave it as an expression in the original string, and continue to the next expression. If the key didn't exist, continue.
• check the model properties for the full expression, including prefix. If the value is null, continue.
• if all this still didn't yield a result, fall back to legacy behaviour: apply the prefix-stripped expression on the model; both ${version} and _${pom.version} will result in _<project><version>. If this approach yields a result, log a warning about deprecation.

The above algorithm won't fix broken poms that use _${version} as a means to refer to the project version. Technically that expression explicitly tells us NOT to look in the pom
since it doesn't have the pom. prefix. The same goes for groupId and artifactId and similar. Either we make these 'special' tokens, or we just enforce the use of ${pom.X}.

The differences between 2.0 and 2.1 are illustrated by this pom:

<project>
  ...
  <version>1.0</version>
  ...
  <dependencies>
    <dependency>
      ..
      <artifactId>A</artifactId>
      <version>${pom.version}</version>
    </dependency>
    <dependency>
      ..
      <artifactId>B</artifactId>
      <version>${version}</version>
    </dependency>
    <dependency>
      ..
      <artifactId>C</artifactId>
      <version>${env.version}</version>
    </dependency>
    <dependency>
      ..
      <artifactId>D</artifactId>
      <version>${pom.env.version}</version>
    </dependency>
  <dependencies>

  <properties>
    <pom.version>2.0</pom.version>
    <version>3.0</version>
    <env.version>4.0</env.version>
    <pom.env.version>5.0</pom.env.version>
  </properties>
</project>

-Dversion=6.0

on the commandline, and

export version=7.0

as an environment var.

The results are:

The fact that B is 3.0 for maven 2.0.x and not 6.0 is because -D doesn't override pom properties (unless that's fixed).

So this is quite disturbing. I think that the expected behaviour is displayed in 2.1.