[jira] [Commented] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://issues.apache.org/jira/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681682#comment-14681682
]
Stephen Evanchik commented on MNG-5315:
---
I'm not sure that the Takari libs work for Maven 3.2.x.
The Takari libs + Maven 3.3.x are an improvement but parallel builds will still
fail. This is due to certain projects having their classpath corrupted.
Successful builds have the correct classpath (obviously); unsuccessful builds
will have an empty classpath.
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://issues.apache.org/jira/browse/MNG-5315
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: Issues to be reviewed for 4.x
>
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=334031#comment-334031
]
Stephen Evanchik commented on MNG-5315:
---
Alternatively one can create a custom Component that adds this without
modifying maven-core. Here is an example against 3.1.2-SNAPSHOT and a 3.0.x:
https://github.com/evanchsa/maven-parallel-resolver.git
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoo
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Evanchik updated MNG-5315:
--
Attachment: MNG-5315-3.0.x.patch
Patch suitable for the 3.0.x branch
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.0.x.patch, MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.project.DependencyResolutionException: Could not
> res
[jira] (MNG-5315) Artifact resolution sporadically fails in parallel builds
[
https://jira.codehaus.org/browse/MNG-5315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Evanchik updated MNG-5315:
--
Attachment: MNG-5315-3.1.2-SNAPSHOT.patch
Simple synchronization as proposed in this issue against 3.1.2-SNAPSHOT
> Artifact resolution sporadically fails in parallel builds
> -
>
> Key: MNG-5315
> URL: https://jira.codehaus.org/browse/MNG-5315
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.4
>Reporter: Ivan S. Dubrov
>Assignee: Jason van Zyl
>Priority: Minor
> Attachments: MNG-5315-3.1.2-SNAPSHOT.patch
>
>
> Artifact resolution can fail during the parallel build if it was downloaded
> during the same session.
> Scenario:
> 1) Delete the whole Maven local repository.
> 2) Run build "mvn compile -T1.5C"
> 3) Build fails (see log extracts below)
> 4) If I run build again, it succeeds.
> It seems like the problem is due to two thread trying to resolve same
> artifact concurrently. This problem never happens once I have all
> dependencies cached in the local repository.
> Extracts from the log output:
> {noformat}Downloading:
> http://nexus/content/repositories/thirdparty/com/googlecode/guava-osgi/guava-osgi/11.0.0/guava-osgi-11.0.0.jar
> 12444/13937 KB ...
> ...
> [DEBUG] Skipped remote update check for commons-cli:commons-cli:jar:1.2,
> already updated during this session.
> [DEBUG] Skipped remote update check for
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0, already updated during this
> session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-api:jar:1.6.4,
> already updated during this session.
> [DEBUG] Skipped remote update check for org.slf4j:slf4j-jdk14:jar:1.6.4,
> already updated during this session.
> ...
> [ERROR] Failed to execute goal on project util: Could not resolve
> dependencies for project com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The
> following artifacts could not be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal on project util: Could not resolve dependencies for project
> com.guidewire.pl:util:bundle:1.0-SNAPSHOT: The following artifacts could not
> be resolved: commons-cli:commons-cli:jar:1.2,
> com.googlecode.guava-osgi:guava-osgi:jar:11.0.0,
> org.slf4j:slf4j-api:jar:1.6.4, org.slf4j:slf4j-jdk14:jar:1.6.4: Failure to
> find commons-cli:commons-cli:jar:1.2 in
> http://nexus/content/repositories/thirdparty was cached in the local
> repository, resolution will not be reattempted until the update interval of
> gw.thirdparty has elapsed or updates are forced
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:210)
> at
> org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:117)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167)
> at
> org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:163)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.apache.maven.project.DependencyResolutionExce
[jira] Commented: (MASSEMBLY-391) Sharing a default assembly descriptor across sub modules does not work if invoked from parent project
[ http://jira.codehaus.org/browse/MASSEMBLY-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165872#action_165872 ] Stephen Evanchik commented on MASSEMBLY-391: Summary: maven-assembly-plugin dependencies are only resolved in superpom's pluginManagement section OR in the declaring POM. Details: My issue is that I started with a project structure of: root -> sub-project -> sub-module I have created a shared-project-assembly and installed it in the repository. I configure the assembly plugin like so: maven-assembly-plugin 2.2-beta-2 my-group shared-project-assembly 0.0.1 . just like in the FAQ . If I place that assembly configuration in a leaf project such as: root -> sub-project -> sub-module-distribution It only works if I invoke mvn package from sub-module-distribution. If I invoke it from sub-project I receive the attached error. However, if I place the plugin configuration in my superpom's pluginManagement section it works just fine. If I make a mistake in the dependency section of the assembly configuration, such as: NOT_THE_RIGHT_GROUP shared-project-assembly 0.0.1 and execute mvn package from sub-project nothing happens, there is no error indicating that Maven is unable to resolve artifact. If I move in to sub-module-distribution and execute mvn package I receive the error indicating that the artifact cannot be resolved. > Sharing a default assembly descriptor across sub modules does not work if > invoked from parent project > - > > Key: MASSEMBLY-391 > URL: http://jira.codehaus.org/browse/MASSEMBLY-391 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Stephen Evanchik >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: test.error > > > I have a multi-project folders setup like one shown below, > > root > |_ sub-folder1 > |_ sub-folder2 > |_ sub-folder3 > |_ etc > > Have a root pom.xml at the root folder level and in that I have defined > > maven-assembly-plugin > > > src/main/assembly/descriptor.xml > > > > > > Above descriptor works fine only if I have defined a descriptor file on the > src/main/assembly folder for each sub-folder1, sub-folder2, etc. > It would be great if maven supports me in defining a common assembly > descriptor and can be shared by all the sub modules from a common location. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-391) Sharing a default assembly descriptor across sub modules does not work if invoked from parent project
[ http://jira.codehaus.org/browse/MASSEMBLY-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Evanchik updated MASSEMBLY-391: --- Attachment: test.error File showing the error > Sharing a default assembly descriptor across sub modules does not work if > invoked from parent project > - > > Key: MASSEMBLY-391 > URL: http://jira.codehaus.org/browse/MASSEMBLY-391 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Stephen Evanchik >Assignee: John Casey > Fix For: 2.2-beta-2 > > Attachments: test.error > > > I have a multi-project folders setup like one shown below, > > root > |_ sub-folder1 > |_ sub-folder2 > |_ sub-folder3 > |_ etc > > Have a root pom.xml at the root folder level and in that I have defined > > maven-assembly-plugin > > > src/main/assembly/descriptor.xml > > > > > > Above descriptor works fine only if I have defined a descriptor file on the > src/main/assembly folder for each sub-folder1, sub-folder2, etc. > It would be great if maven supports me in defining a common assembly > descriptor and can be shared by all the sub modules from a common location. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-391) Sharing a default assembly descriptor across sub modules does not work if invoked from parent project
Sharing a default assembly descriptor across sub modules does not work if invoked from parent project - Key: MASSEMBLY-391 URL: http://jira.codehaus.org/browse/MASSEMBLY-391 Project: Maven 2.x Assembly Plugin Issue Type: New Feature Affects Versions: 2.0.1 Reporter: Stephen Evanchik Assignee: John Casey Fix For: 2.2-beta-2 I have a multi-project folders setup like one shown below, root |_ sub-folder1 |_ sub-folder2 |_ sub-folder3 |_ etc Have a root pom.xml at the root folder level and in that I have defined maven-assembly-plugin src/main/assembly/descriptor.xml Above descriptor works fine only if I have defined a descriptor file on the src/main/assembly folder for each sub-folder1, sub-folder2, etc. It would be great if maven supports me in defining a common assembly descriptor and can be shared by all the sub modules from a common location. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3751) Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository
Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository --- Key: MNG-3751 URL: http://jira.codehaus.org/browse/MNG-3751 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies, Reactor and workspace Affects Versions: 2.0.9, 2.0.8 Environment: Mac OS X 10.5.4, Windows XP SPx, CentOS 5.2 Reporter: Stephen Evanchik Attachments: full-dependency-tree.txt, master-compile-run.txt, maven-test.tar.gz Summary: Multi-module project is non-deterministic in evaluating reactor artifacts defined as dependencies unless they are installed in the local repository I cannot build either a leaf project (sub1-module1) or the master project (master) until I 'mvn install' the sub-modules (sub-module). I believe that dependency modules found only in the reactor should be added to: [DEBUG] (f) classpathElements = [/Users/evanchsa/src/maven-test/subproject1/sub1-module1/target/classes] Detailed setup: I have a multi-module project that is laid out in the following POM inheritance (this is not the filesystem layout): master + sub1-master - sub1-module1 - sub1-module2 + sub2-master - sub2-module1 - sub2-module2 Sub-modules are type "jar" and 1 "war" and there are dependencies within the sub-modules as follows (using mvn dependency:tree): 1. sub1-module1 - Depends on no other modules 2. sub1-module2 - test-group:sub1-module2:jar:0.0.1 \- test-group:sub1-module1:jar:0.0.1:compile 3. sub2-module1 - test-group:sub2-module1:jar:0.0.1 \- test-group:sub1-module2:jar:0.0.1:compile \- test-group:sub1-module1:jar:0.0.1:compile 4. sub2-module2 (this is the WAR) - test-group:sub2-module2:jar:0.0.1 \- test-group:sub2-module1:jar:0.0.1:compile \- test-group:sub1-module2:jar:0.0.1:compile \- test-group:sub1-module1:jar:0.0.1:compile Project filesystem layout: build/master/pom.xml subproject1/sub1-master/pom.xml subproject1/sub1-module1/pom.xml subproject1/sub1-module2/pom.xml subproject2/sub2-master/pom.xml subproject2/sub2-module1/pom.xml subproject2/sub2-module2/pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
