Maven 2 project versions, dependency versions, and perpetual releasing

Answer 1

This is really the same problem as someone needing to branch code they are working on. You need some form of identifier to be able to get at the specific version until you merge back to the mainline development of that component.

The dependency classifier may be something worth looking into. You'll still need to have developers that will properly identify their modified code.

Answer 2

we work with a "Super Parent".pom-project, in it the versions are defined as properties and in every child.project, the versions are set with those properties

in addition the real projects have no version set, instead they inherit it from their parent pom-project (incl. groupId etc.)

with this set up the versions are only defined in some parent pom-projects, thus the needed setup is minimized

e.g. this structure

• super parent pom-project (all 3rd party versions as properties defined, e.g. 2.5.6 spring-framework) ---- persistence-parent pom-project, inherits all from super parent ------ persistence-foobar jar project, inherits all from persistence-parent ---- util-parent

etc.

only versions you see are the ones inside the parent relations example:

        <modelVersion>4.0.0</modelVersion>
<artifactId>foo-bar-foo</artifactId>
<packaging>jar</packaging>
<name>whatever</name>
<description>...</description>
<parent>
    <groupId>org.foo.bar</groupId>
    <artifactId>persistence-parent</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
    </dependency>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-bar</artifactId>
        <version>${project.version}</version>
        <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>org.springframework.jdbc</artifactId>
        <version>${parent.spring.version}</version>
    </dependency>

it works this way, because inside the pom you can use already defined values like version, even if the version is set via inheritance

we combine this with module setups inside the parent projects to make the builds easier

Answer 3

This is something I find very difficult with maven and internal projects; you have two version control systems (maven's, which, quite frankly, isn't very good) and your source code control's (which, assuming it's CVS or better, supports real workflow).

Here's how we do it:

report --depends on--> core
web    --depends on--> core

We use the maven release plug:

report's pom, during development, would have a SNAPSHOT version matching what's in core's pom. I do a mvn clean install in core, then I can see those changes in report in my local environment.

When I do a release of report, I must first release core via the maven release plug. When I I use it on core, it asks me to set the version of core to release (i.e. remove the -SNAPSHOT), to which I say yes, and the resulting released artifact doesn't depend on a SNAPSHOT release. When the release plugin is done, the report pom now depends on the next SNAPSHOT release of core (though you can override this during mvn release:prepare if you want).

The devs on web then get an email that a new version of core is available and they can choose to use it if they wish. Our policy is that they should update before releasing.

Answer 4

Try to layout your builds such that modules that need to be developed together are released together. This will let the maven release plugin do most of the work for you.

For dependencies that really should have a separate lifecyle...because they change infrequently or are shared by multiple projects, you want to handle those differently. They way I do it is to keep the dependencies at the last release version until a change actually requires an upgrade to the next snapshot. In this way when you go to release the product, you will find all the things that may also be released simply by following the snapshot trails.

I find it also helpful to keep the external dependency versions specified as properties in the top pom of my project. This makes it easy to see at a glance what needs to be released. You can see an example of the Nexus pom here (look down around line 120).