Page History

...

1. Maven currently does not allow variables in any of the elements within the parent section. MNG-624 in particular focuses on the version element. In a multiproject build it is common for all the subprojects to inherit from the same parent. Frequently the parent (or some other ancestor) identifies the specific versions of dependent artifacts. When a change occurs, such as updating a dependency version, the version of the parent must be changed. This requires that each subproject pom must also be changed to reflect the new parent version. This is tedious, time consuming and very annoying. In fact, this has become the most asked for feature in Maven.
2. When maven installs or deploys an artifact the pom is copied from the source directory to the local or remote repository without modification. So a pom that looks like

   Code Block
   xml xml borderStyle solid xml
   <project> ... <groupId>org.apache.maven</groupId> <artifactId>demo</groupId> <version>${myVersion}</version> </project>

   and where myVersion is set to 1.0.0 will be deployed to /org/apache/maven/demo/1.0.0/demo-1.0.0.pom and will still contain ${myVersion} as the "value" of the version element. This could lead to the odd case of a dependency being specified with 1.0.0 as the version and myVersion never being specified, or worse being set to a value other than 1.0.0.  If one were to assume that item 1 above was the be fixed then this issue must also be addressed. If a project is deployed with its parent version (or any of the other parent elements) set to variables then it is impossible to guarantee that the build will always be reproducable since the parent version variable would have to be set either in a settings file or from the command line, neither of which can be guaranteed from one build to the next. Worse, any project that has a dependency on such a project would also have to define the variable in a settings file or on the command line.

...

As a concrete example consider the following projects:

/project/pom.xml

<project>
  <groupId>org.apache.maven</groupId>
  <artifactId>parent</artifactId>
  <version>1.0</version>
</project>

/project/child/pom.xml

<project>
  <artifactId>child</artifactId>
  <parent>
    <groupId>org.apache.maven</groupId>
    <artifactId>parent</artifactId>
    <version>1.0</version>
  <parent>
</project>

/project/child/grandchild/pom.xml

<project>
  <artifactId>grandchild</artifactId>
  <version>1.0</version>
  <parent>
    <groupId>org.apache.maven</groupId>
    <artifactId>child</artifactId>
  <parent>
</project>

In this case an attempt to build the grandchild before building the child will fail since the child does not contain its own version. However, building the child without building the parent would succeed, if the parent directory contains the pom.xml since the parent pom identifies its own version. Once a maven goal is run on the child project its target directory will then contain a pom.xml that looks like:

<project>
  <groupId>org.apache.maven</groupId>
  <artifactId>child</artifactId>
  <version>1.0</version>
  <parent>
    <groupId>org.apache.maven</groupId>
    <artifactId>parent</artifactId>
    <version>1.0</version>
  <parent>
</project>

...