We stuck with relative paths in 2.0. In 2.1, this should be:

<modules>
  <module>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version> (optional, obviously)
  </module>
</modules>

This makes it the inverse of the <parent/> relationship, which makes sense. We would then have hinting for <relativePath/>, a search path for the modules (default being */pom.xml) etc.

Note that we can reuse the syntax, as the model version would be 4.1.0 and we can select the parser based on the model version (hopefully). To save confusion, perhaps we can find a more appropriately named tag, however.

This should all tie in to workspaces.

  • No labels

1 Comment

  1. Unknown User (skaze)

    moving away from directory based module definitions would get round some of the other 'hidden' couplings such as maven SCM URLs being built using artifactIds when real SCM system is all about directories. Same applies for site:deploy which builds the site directory hierarchy based on artifactIds and not the project's originating directory structure. All of which arises from the fact that a module project's directory is not necessarily the same as the module project's artifactId.