tags:

views:

21

answers:

2

I don't know if I'm missing something, but I have a problem with the Codehaus versions plugin for Maven. Here's a simplification of my situation:

  • root:
    • moduleA
    • moduleB

'root' is an aggregator POM, i.e. declaring moduleA and moduleB as child modules, and A and B both have root as parent.

Both A and B have a dependency on project-C, but the version of this dependency is defined in a property - say <project-C.version> - not hardcoded. This property is defined in root, so both A and B inherit the same version value for project-C.

In root POM:

<properties>
    <project-C.version>1.0</project-C.version>

In module A and B (remember root is parent):

<dependency>
    <groupId>com.blah</groupId>
    <artifactId>project-C</artifactId>
    <version>${project-C.version}</version>
</dependency>

Now, say newer version 1.1-SNAPSHOT of project-C becomes available. I want to use the versions plugin to show this to me, so I run:

$ cd /projects/root
$ mvn versions:display-property-updates -DallowSnapshots=true

but all I get is something like this:

[INFO] Building root  
[INFO] This project does not have any properties associated with versions

[INFO] Building moduleA  
[INFO] This project does not have any properties associated with versions

[INFO] Building moduleB  
[INFO] This project does not have any properties associated with versions

It doesn't make a difference if I run it on root, moduleA or moduleB: it always says that. Of course it works if I hardcode project-C's version number in the dependencies.

So, in summary: I want to centralise dependency versions as properties in a root (aggregator/parent) POM, and I want the versions plugin to pick those up for goals that work on properties, i.e.:

  • display-property-updates
  • update-properties

How do I do this? Am I missing something? Is this a bug in versions plugin?

+1  A: 

This seemed to be a job for dependencyManagement section in your root pom...

khmarbaise
Yeah, I'm considering that, but it will be much more verbose than the property solution.
Cornel Masson
+1  A: 

It looks like the answer you received in MVERSIONS-123 is not accurate:

If the properties are defined in the parent pom, then run the goal from the parent pom (including the child projects as part of the aggregator if necessary in order to pick up the dependencies)

This part is not true, or at least doesn't occur. It seems the versions plugin only look or properties in the current pom. Declaring the following in the parent does work:

<properties>
    <project-C.version>1.0</project-C.version>
</properties>

<dependencies>
  <dependency>
    <groupId>com.blah</groupId>
    <artifactId>project-C</artifactId>
    <version>${project-C.version}</version>
  </dependency>
</dependencies>

But declaring the property in the parent and the dependency in the child doesn't (even when running the plugin on the parent).

Now, if the behavior described by Stephen in MVERSIONS-123 is the expected behavior, then there is a bug (and you should actually provide a simple project allowing to reproduce, I did a simple test with Junit as dependency).

But in your case (it was maybe just an example though) since both A and B depend on C, why don't you put C in the parent? This would work. You should use dependencyManagement anyway (and this will work if you don't want to inherit it everywhere).

Pascal Thivent
Thanks, @Pascal. I suspect it's a bug in the plugin, as you succinctly put it: 'But declaring the property in the parent and the dependency in the child doesn't (even when running the plugin on the parent).' I'll knock up an example and add it to MVERSIONS-123.I'll switch to the `dependencyManagement` solution now.
Cornel Masson
@Cornel I agree. And uploading a sample demo project will certainly increase the chances to get the issue reopened. There is something wrong.
Pascal Thivent