tags:

views:

114

answers:

1

We're optimizing our Maven configuration (from previously using ant) and I've just read the Maven by Example book from Sonatype. Duplicating configurations has gotten us in trouble in the past, so I absolutely want to avoid even the tiniest bit of this.

The above book mentions to use the built-in project.groupId and project.version properties from a parent module when referring to the other sibling submodules as dependencies:

<dependency>
  <groupId>${project.groupId}</groupId>
  <artifactId>model</artifactId>
  <version>${project.version}</version>
</dependency>

That works great, I love it. But this doesn't work in the tag of the submodule pom.xml's:

<parent>
    <groupId>${project.groupId}</groupId>
    <artifactId>${project.artifactId}</artifactId>
    <version>${project.version}</version>
    <relativePath>../pom.xml</relativePath>
</parent>

I guess not a big deal, seems like I can create properties for these, but with many modules I'd really like to fully understand the best practices for these kinds of issues..

UPDATE The best way so far it seems to do this is the following. A bit ugly, but eliminates duplicate hard-coded values. parent pom.xml:

<groupId>${groupId}</groupId>
<artifactId>${artifactId}</artifactId>
<packaging>pom</packaging>
<version>${version}</version>
<properties>
    <groupId>com.mycompany</groupId>
    <artifactId>mycompany</artifactId>
    <version>1.0</version>
</properties>

child pom.xml:

<parent>
    <groupId>${groupId}</groupId>
    <artifactId>${artifactId}</artifactId>
    <version>${version}</version>
    <relativePath>../pom.xml</relativePath>
</parent>
<artifactId>child</artifactId>
A: 

That works great, I love it. But this doesn't work in the tag of the submodule pom.xml's (...)

This can't work, chicken and egg problem: you can't get the coordinates of the parent to use from the parent.

I guess not a big deal, seems like I can create properties for these, but with many modules I'd really like to fully understand the best practices for these kinds of issues

Well, assuming it would work (and to my knowledge, properties are not expanded in the parent element so it won't), where would put these properties? In the parent? Same problem as above. In the child? No point. So in short, you need to hard-code these values in the parent element

Note that this is not a problem for the groupId and artifactId as they don't change; however, it's more annoying for the version and I suggest to either use the Maven Release Plugin or the Versions Maven Plugin (and its versions:update-child-modules goal).

PS: Maven 3.1 will support version-less parent element (see MNG-624).

Related answers


Why can't I get the coordinates for the parent from the parent? The relativePath should give me access to the parent pom. So it actually works if you add the groupId, artifactId and version as properties in the parent and then reference those properties FOR the parent in the child. So that there's no duplicated values, the corresponding hard-coded elements in the parent were replaced also with references to the properties. It seems like an ugly way to go about this, but it works...

No, it does NOT work, property substitution is not allowed in the parent element (for later reproducibility). That's how it is designed in Maven 2.x. See MNG-624 and the millions of threads about this on the users mailing list, e.g.:

You asked about the best practice, I answered: hard-code everything in the parent element. Period.

Pascal Thivent
Why can't I get the coordinates for the parent from the parent? The relativePath should give me access to the parent pom. So it actually works if you add the groupId, artifactId and version as properties in the parent and then reference those properties FOR the parent in the child. So that there's no duplicated values, the corresponding hard-coded elements in the parent were replaced also with references to the properties. It seems like an ugly way to go about this, but it works...
at
hmm.. I don't know what to say, property substitution does seem to be working fine. I'll update my question to make sure we're talking about the same thing. I'm curious though, why would this not be encouraged? Why have duplicate hard coded values littered among many modules?
at
@at You think it is, but it isn't (you can't build the child in isolation, the installed / deployed / released poms are not correct). Hardcode the values. I think I provided enough references, just check them if you don't trust me (it's not like you're the first one to think about this).
Pascal Thivent
@Pascal just noticed this question from a few weeks ago. We are currently fully deploying locally and to production with 5 modules with 1 parent. The parent defines groupId, artifactId and version properties. We use those everywhere, for the parent's groupId, artifactId, version and the child module's equivalent as well.
at
@at I'm not sure to understand what you're talking about. Anyway, don't take it bad but I won't spend more time on this. You asked for the best practice, I gave you the best practice, backed up with solid *references*. You don't like the answer and want to workaround the rule. Fine. But I'm sure of what I'm saying, what you are doing doesn't fully work (you just think it is).
Pascal Thivent