Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 05:12:45 -0700 hat Jamie Whitehouse jamie.whiteho...@alcatel-lucent.com geschrieben: The use of an explicit version is the problem. Instead of 0.0.3-SNAPSHOT try depending on ${project.version}. In my experience using the fixed version the assembly plugin (and others like the dependency copy goals) will use what's in the local repo not what's in the reactor. As suggested I changed the dependency versions to ${project.version}, but it did not help. The release:prepare goal aborts with the same error: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] -- -- [INFO] [INFO] Failed to create assembly: Failed to resolve dependencies for proj ect: com.acme:commons.distribution:pom:0.0.6 [INFO] [INFO] Missing: [INFO] -- [INFO] 1) com.acme:commons.util:jar:0.0.6 [INFO] [INFO] Try downloading the file manually from the project website. [INFO] [INFO] Then, install it using the command: [INFO] mvn install:install-file -DgroupId=com.acme -DartifactId=commo ns.util -Dversion=0.0.6 -Dpackaging=jar -Dfile=/path/to/file [INFO] [INFO] Alternatively, if you host your own repository you can deploy the file there: [INFO] mvn deploy:deploy-file -DgroupId=com.acme -DartifactId=commons .util -Dversion=0.0.6 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -Dreposit oryId=[id] [INFO] [INFO] Path to dependency: [INFO] 1) com.acme:commons.distribution:pom:0.0.6 [INFO] 2) com.acme:commons.util:jar:0.0.6 [INFO] [INFO] 2) com.acme:commons.util.test:jar:0.0.6 [INFO] [INFO] Try downloading the file manually from the project website. [INFO] [INFO] Then, install it using the command: [INFO] mvn install:install-file -DgroupId=com.acme -DartifactId=commo ns.util.test -Dversion=0.0.6 -Dpackaging=jar -Dfile=/path/to/file [INFO] [INFO] Alternatively, if you host your own repository you can deploy the file there: [INFO] mvn deploy:deploy-file -DgroupId=com.acme -DartifactId=commons .util.test -Dversion=0.0.6 -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -Dre positoryId=[id] [INFO] [INFO] Path to dependency: [INFO] 1) com.acme:commons.distribution:pom:0.0.6 [INFO] 2) com.acme:commons.util.test:jar:0.0.6 Note that building the assembly runs fine. Only when the build is started in the context of mvn release:prepare the error occurs. -Original Message- From: Markus Muenkel [mailto:markus.muen...@fernuni-hagen.de] Sent: Tuesday, May 18, 2010 6:54 AM To: Maven Users List Subject: Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly Am Tue, 18 May 2010 09:10:05 +0100 hat Stephen Connolly stephen.alan.conno...@gmail.com geschrieben: On 18 May 2010 08:40, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
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 goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase goals goalsingle/goal /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 18 May 2010 08:40, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase ^^^ good, if you use a phase prior to package it would fail goals goalsingle/goal ^^^ good that is the correct goal to call /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 09:10:05 +0100 hat Stephen Connolly stephen.alan.conno...@gmail.com geschrieben: On 18 May 2010 08:40, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase ^^^ good, if you use a phase prior to package it would fail goals goalsingle/goal ^^^ good that is the correct goal to call /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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 groupIdcom.acme/groupId artifactIdcommons.util/artifactId version0.0.3-SNAPSHOT/version /dependency dependency groupIdcom.acme/groupId artifactIdcommons.util.test/artifactId version0.0.3-SNAPSHOT/version /dependency /dependencies while the assembly_descriptor.xml contains dependencySets dependencySet includes includecom.acme:commons.util:jar/include includecom.acme:commons.util.test:jar/include /includes unpackfalse/unpack outputDirectory${bundles.folder}/outputDirectory outputFileNameMapping${artifact.groupId}.${artifact.artifactId}-${artifact.version}.${artifact.extension} /outputFileNameMapping useProjectArtifactfalse/useProjectArtifact /dependencySet /dependencySets what is the
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
Am Tue, 18 May 2010 09:10:05 +0100 hat Stephen Connolly stephen.alan.conno...@gmail.com geschrieben: On 18 May 2010 08:40, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase ^^^ good, if you use a phase prior to package it would fail goals goalsingle/goal ^^^ good that is the correct goal to call /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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 groupIdcom.acme/groupId artifactIdcommons.util/artifactId version0.0.3-SNAPSHOT/version /dependency dependency groupIdcom.acme/groupId artifactIdcommons.util.test/artifactId version0.0.3-SNAPSHOT/version /dependency /dependencies while the assembly_descriptor.xml contains dependencySets dependencySet includes includecom.acme:commons.util:jar/include includecom.acme:commons.util.test:jar/include /includes unpackfalse/unpack outputDirectory${bundles.folder}/outputDirectory outputFileNameMapping${artifact.groupId}.${artifact.artifactId}-${artifact.version}.${artifact.extension} /outputFileNameMapping useProjectArtifactfalse/useProjectArtifact /dependencySet /dependencySets what is the
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 18 May 2010 11:56, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: Am Tue, 18 May 2010 09:10:05 +0100 hat Stephen Connolly stephen.alan.conno...@gmail.com geschrieben: On 18 May 2010 08:40, Markus Muenkel markus.muen...@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 Yes, it is goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase ^^^ good, if you use a phase prior to package it would fail goals goalsingle/goal ^^^ good that is the correct goal to call /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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 groupIdcom.acme/groupId artifactIdcommons.util/artifactId version0.0.3-SNAPSHOT/version /dependency dependency groupIdcom.acme/groupId artifactIdcommons.util.test/artifactId version0.0.3-SNAPSHOT/version /dependency /dependencies while the assembly_descriptor.xml contains dependencySets dependencySet includes includecom.acme:commons.util:jar/include includecom.acme:commons.util.test:jar/include /includes unpackfalse/unpack outputDirectory${bundles.folder}/outputDirectory
RE: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
The use of an explicit version is the problem. Instead of 0.0.3-SNAPSHOT try depending on ${project.version}. In my experience using the fixed version the assembly plugin (and others like the dependency copy goals) will use what's in the local repo not what's in the reactor. -Original Message- From: Markus Muenkel [mailto:markus.muen...@fernuni-hagen.de] Sent: Tuesday, May 18, 2010 6:54 AM To: Maven Users List Subject: Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly Am Tue, 18 May 2010 09:10:05 +0100 hat Stephen Connolly stephen.alan.conno...@gmail.com geschrieben: On 18 May 2010 08:40, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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 artifactIdmaven-assembly-plugin/artifactId executions execution idmake-assembly/id phasepackage/phase ^^^ good, if you use a phase prior to package it would fail goals goalsingle/goal ^^^ good that is the correct goal to call /goals /execution /executions configuration descriptors descriptorassembly_descriptor.xml/descriptor /descriptors finalNamecommons/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
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
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 goalsingle/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 - 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 17 May 2010 14:13, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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 goalsingle/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? 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: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release:prepare fails with missing artifacts when project to be released runs an assembly
On 11 May 2010 17:16, Markus Muenkel markus.muen...@fernuni-hagen.dewrote: 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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
mvn release:prepare fails with missing artifacts when project to be released runs an assembly
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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org