Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • A <version> that was omitted in a <parent> section is easy to resolve. You follow the <relativePath> (../pom.xml by default) and look for the parent POM. If it is there, you can read it and have its version (like it already works but the version is then matched to the one specified in <parent>). If it is NOT there maven will simply fail with a message like "Parent POM not found at <relativePath>! You have to specify the version of the parent if it is not locally available".
  • A <version> that was omitted in a <dependency> section can only be resolved if the referenced modules are resolved. So if it is NOT part of the sub-tree where the build was invoked we have a problem to solve. However this can be done by adding a list of projects named "closure" similar to the reactor but that is build from the toplevel-pom recursively following the <modules>. This list would be lazy evaluated so it only has to be build once when required at all (might fit together with http://jira.codehaus.org/browse/MNG-2675). To say this again with other words: If mvn was called on the toplevel-pom the reactor and the "closure" would be equal. So if an omitted <version> is hit, maven tries to find the project in the reactor. If it is NOT in reactor, maven will get the "closure", that will be build on the first call. Then it tries to find the project in the "closure". If the project was found in the end, the version is filled in - otherwise the build fails.

...