maven deploy changed artifacts only

Question

Hi, Im using maven 2.2 with nexus 1.4.0

Let's say I have a pom-structure like this (with corresponding versions)

parentproj, v1.0.1
 - childproj1, v1.0.2
 - childproj2, v1.0.7

childproj1 and childproj2 represent different parts of the application (e g gui and backend) and I want to be able to keep their versions separate so that I can release a new version of the backend without having to release a new version of the gui.

Now, to deploy this structure to Nexus it would be convenient to go to parentproj and say

mvn deploy -DperformRelease=true

which would deploy all artefacts to the Nexus realease repository. This works fine the first time I deploy it, but the second time I run into problems: let's say that I made an update to childproj1 so that we now have the following versions:

parentproj, v1.0.1
 - childproj1, v1.0.3
 - childproj2, v1.0.7

In this situation Nexus will not let me do mvn deploy from parentproj, since it already has a copy of childproj2 in the 1.0.7 version. Nexus will say "Resource, illegal request:Repository with ID='releases' does not allow updating artifacts." This is fine, I don't want to update existing versions by mistake.

But I guess that what I would like to do is to be able to tell maven something like "deploy only those artifacts that have versions that are not already present in the release repository".

Is there a way to do this, or would I have to deploy each project by itself?

Thanks, D

Answer 1

In my experience, it has been easier to deploy everything, and often use the same version number for all the components. For example, if my team is working on version 1.0.7, all the submodules have the version number of 1.0.7-SNAPSHOT, until we release, even if no code has changed in certain modules. Then when we deploy, we would deploy the whole application. I think it has several advantages over a piecemeal deployment. First, if you every have to rollback to the last stable version, you just have to rollback to 1.0.6 for all modules--you don't have to remember that the backend was 1.0.3 while the GUI was 1.0.6. Second, it ensures that all the components are compiled correctly against each other and have been tested as a logical group.

Sorry, I know this isn't a specific answer to your question, but, at least in my team's case, it was useful to think slightly differently