On 18 May 2010 08:40, Markus Muenkel <[email protected]>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
>>>>
>>>>
>>>> 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>
>
^^^ good, if you use a phase prior to package it would fail
> <goals>
> <goal>single</goal>
>
^^^ good that is the correct goal to call
> </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)
>
are they also listed as dependecies of commons.distribution?
what is the build plan?
to find the build plan run
mvn validate
and the build plan is the listing of projects in the order they will be
built.
commons.distribution needs to come after the ones you want to include.
>
> - 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]
>
>
