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
Yes, it is <goal>single</goal>
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
3. mvn versions:revert
I executed this test procedure on the assembly project
and in fact it
produces the same problem as described above: the
artifacts to be assembled
are looked up in the repository with version
0.0.3-reltesting-SNAPSHOT and
the build fails because the artifacts have not yet been
installed with this
version.
For me it looks like a hen-and-egg problem: releasing
the assembly project
implies building the assembly in the release version,
but the assembly in
turn requires the released artifacts to be installed in
the repository.
Would it be possible to have the release procedure work
like this:
1) Release plugin changes the version in the multi
module project (that
includes the assembly project and the artifacts to be
assembled), i.e. to
0.0.4
2) The artifacts to be assembled are built and installed
in the repository
in version 0.0.4
3) The assembly is run and picks up the artifacts to be
assembled from the
repository in version 0.0.4
4) The assembly project is installed in the repository
in version 0.0.4
Currently the install step in 2) is not happening --
this seems to be the
crucial part
If you bind things to the correct phases and have the
correct project
structure then there is no need to invoke the local
repository and
everything is resolved from the reactor.
You just need to restructure your project.
Where is the assembly created?
Where is that in relation to it's dependencies?
The project structure is currently as follows:
commons
|
|-- commons.util
|
|-- commons.util.test
|
|-- commons.distribution
| |
| |-- assembly_descriptor.xml
where commons.distribution is the "assembly project". Its
pom.xml configures the assembly plugin like this:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
<configuration>
<descriptors>
<descriptor>assembly_descriptor.xml</descriptor>
</descriptors>
<finalName>commons</finalName>
</configuration>
</plugin>
The projects contained in the assembly are the two sibling
projects commons.util and commons.util.test (both are Java
projects packaged as jar). They are included in the
assembly descriptor via dependencySets (I'm not sure if
moduleSets would be more appropriate in this case)
- Markus
you cannot create an assembly in a project which is the
xpath:/project/parent of the dependencies to be included
in the assembly
-Stephen
- Markus
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: [email protected]
For additional commands, e-mail: [email protected]
