On 18 May 2010 11:56, Markus Muenkel <[email protected]>wrote:
> Am Tue, 18 May 2010 09:10:05 +0100 hat > Stephen Connolly <[email protected]> geschrieben: > >> 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? >> > > Yes, they are listed as > <dependencies> > <dependency> > <groupId>com.acme</groupId> > <artifactId>commons.util</artifactId> > <version>0.0.3-SNAPSHOT</version> > </dependency> > <dependency> > <groupId>com.acme</groupId> > <artifactId>commons.util.test</artifactId> > <version>0.0.3-SNAPSHOT</version> > </dependency> > </dependencies> > > while the assembly_descriptor.xml contains > > <dependencySets> > <dependencySet> > <includes> > <include>com.acme:commons.util:jar</include> > <include>com.acme:commons.util.test:jar</include> > </includes> > <unpack>false</unpack> > <outputDirectory>${bundles.folder}</outputDirectory> > > > <outputFileNameMapping>${artifact.groupId}.${artifact.artifactId}-${artifact.version}.${artifact.extension} > </outputFileNameMapping> > <useProjectArtifact>false</useProjectArtifact> > </dependencySet> > </dependencySets> > > >> 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. >> >> Forgot to attach the build plan - here it is: > > [INFO] Reactor build order: > [INFO] com.sap.helix.commons > [INFO] com.sap.helix.commons.util > [INFO] com.sap.helix.commons.util.test > [INFO] com.sap.helix.commons.distribution ^^^^ that's the correct build order so clean verify should work... hmmmm > > > 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] >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
