How to handle maven versions in a multi module project?

I have a maven project infrastructure like this:

/trunk/all/pom.xml
/trunk/all/libs/lib1/pom.xml
               /lib2/pom.xml
               ...
/trunk/all/projects/p1/pom.xml
                   /p2/pom.xml
                   ...

You see, I have a lot of libraries and a lot of projects using these libraries.

All this is combined to one multi module project, because I like to

• import the top project into eclipse and have all my libraries and projects available at once
• only do a single mvn test to compile and test all my code after I've done some global refactorings.

Currently, all my modules are version 1.0-SNAPSHOT.

Now I want to release project p2 and all libs p2 uses (e.g. lib1 and lib2) to version 1.0. After that I do some code modifications on lib1, but none on lib2.

I want the next release of p2 being version 1.1, using lib1 in version 1.1 (it was modified since the last release), but lib2 still in version 1.0 (since it wasn't modified).

More general: If I do a release, I want to increase the minor numbers of the project being released开发者_StackOverflow社区 and of all changed libraries since the last release.

Question

Do I have to take care for all the module versions by myself or is there a plugin that is able to do the required work for me?

Do I have to take care for all the module versions by myself or is there a plugin that is able to do the required work for me?

Well, if you don't want to keep the versions of the various artifacts (projects, libs) in sync with the version defined in all/pom.xml (i.e. just inherit it through the whole hierarchy), I'm afraid you'll have to start to manage them manually. I'm just not sure to understand why you wouldn't bump the version of say lib2 even if you didn't make any change to it. With your current svn repository structure, all artifacts have the same release lifecycle somehow (when you'll tag the trunk, you'll tag everything in it).

Now, if p1 and p2 (I'll ignore the libs for the sake of simplicity) have an independent release cycle, I would recommend a multiple "trunk/tags/branches" structure as described in this thread:

myrepo
  + .links (2)
    + trunks
      + pom.xml
  + parent-pom (1)
    + trunk
      + pom.xml
  + project-A
    + trunk
      + pom.xml
  + project-B
    + trunk
      + pom.xml 

1) The parent POM of the project has an own release cycle. Every component's POM will use it as parent (referenced simply with groupId and artifactId, no relativePath). For a release you'll have to release the parent POM first.

2) This is a construction to enable easy check outs of a specific branch of the project i.e. normally the trunk. A subversion user checks out myrepo/.links/trunk to get the head revision of all sources. The trick is, that that directory contains external links (i.e. with the svn:externals property) to the trunks of all other modules of this project (parent-pom, project-A, project-B). The pom.xml in this directory is never released, it contains simply a modules section for the three modules to enable a multi module build. With this construct you're able to setup easily branches e.g.:

myrepo
  + .links
    + branch-2.x
      + pom.xml

I've used this setup many times (I already wrote about it here on SO, see the related questions below), it works very well. Actually, many projects, including Maven, are using this approach, it's not a fantasy one.

This will not solve your "automagic" version handling (I don't know any solution for that) but at least, this structure plays nicely with the Maven Release Plugin and would support your independent release cycle requirements.

See also

• Building Maven
• XWiki Platform Structure
• Cargo SVN

Related questions

• Maven parent pom vs modules pom
• Migrating to maven from an unusual svn directory structure?

HI! Maybe I'm missing something, but if your libs/modules start feeling the need to have their own version numbers, isn't that an indication that they are growin up and taking on a life of their own - i.e. becoming separate-ish projects in their own right?

Meaning it might make sense to treat them as such - treat them as separate projects, pushed to some mvn repo, and added to the core project as normal dependencies?

Sorry if I'm missing the point somehow, but I've been running into multi-module project "issues" myself....and maybe the issue isn't really an issue at all?