mvn release:prepare fails with missing artifacts when project to be released runs an assembly

[Markus Muenkel <Ma...@FernUni-Hagen.de>]

I'm releasing a Maven2 multi-module project. One of the 
modules is a POM project ("assembly project") that uses 
the maven-assembly-plugin in order to build an assembly 
(zip archive). The artifacts to be assembled are specified 
via dependencies in the POM. They point to modules 
contained in the same multi-module project.

When running mvn release:prepare on the multi-module 
project, the build of the assembly project fails with the 
message that the dependencies cannot be resolved. These 
dependencies are reported with the version that should be 
released, e.g. 0.0.3. Before running the goal, all 
dependency versions are 0.0.3-SNAPSHOT.

What seems to happen is that the snapshot version 
0.0.3-SNAPSHOT is replaced by 0.0.3 and then the assembly 
plugin is started (which is bound to the package phase). 
The assembly plugin tries to resolve the dependencies 
based on version 0.0.3 which however do not yet exist at 
that point.

I guess it is not a problem in Maven but I'm missing 
practice on how to perform a successful release in this 
situation.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly

[Stephen Connolly <st...@gmail.com>]

On 11 May 2010 17:16, Markus Muenkel <Ma...@fernuni-hagen.de>wrote:

> I'm releasing a Maven2 multi-module project. One of the modules is a POM
> project ("assembly project") that uses the maven-assembly-plugin in order to
> build an assembly (zip archive). The artifacts to be assembled are specified
> via dependencies in the POM. They point to modules contained in the same
> multi-module project.
>
> When running mvn release:prepare on the multi-module project, the build of
> the assembly project fails with the message that the dependencies cannot be
> resolved. These dependencies are reported with the version that should be
> released, e.g. 0.0.3. Before running the goal, all dependency versions are
> 0.0.3-SNAPSHOT.
>
> What seems to happen is that the snapshot version 0.0.3-SNAPSHOT is
> replaced by 0.0.3 and then the assembly plugin is started (which is bound to
> the package phase).


what goal did you bind with?

It needs to be assembly:single


> The assembly plugin tries to resolve the dependencies based on version
> 0.0.3 which however do not yet exist at that point.
>

The exist in the reactor, providing the project in which assembly is being
invoked has dependencies on those artifacts so that maven knows the build
order must build the dependent projects first.

to test if you have this working, here is a simple test procedure:
1. mvn versions:set -DnewVersion=0.0.3-reltesting-SNAPSHOT
2. mvn clean verify
3. mvn versions:rollback

it is essential that you only run up the lifecycle as far as verify when
testing, as if you go as far as install, the artifacts will have been pushed
to the local repo (and hence issues with your reactor will be missed)

If you are under the clock [i.e. your manager is saying "this needs to be
released yesterday, why did you recommend maven, your future at this company
is being questioned"] then just change the preparationGoals from "clean
verify" to "clean install" to get a release out the door. But the reality is
that such a release can end up with mixed build artifacts, wherein the
dependencies copied into your assembly where the ones built during the
release:prepare, while the same artifacts copied to your remote repository
were built during release:perform... so that if somebody checks say the md5
of the jar inside the assembly against the md5 of that same jar deployed to
the maven repo, they will find that the checksums do not match (different
timestamps)... additionally, if you use remoteTagging (which you pretty much
need to) and somebody commits while release:prepare is running, then the
release:perform will checkout different code and the subtle issues of
bundled artifact mismatches _will_ bite you in the ass.

So what I am saying is that you need to fix it so that your build works with
"clean verify" on a virgin version number (i.e. a version number that has
never been built before)... but if time pressures are forced on you, you can
get a release out... just don't forget to fix the real problem

-Stephen

I guess it is not a problem in Maven but I'm missing practice on how to
> perform a successful release in this situation.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>