[jira] (MASSEMBLY-658) Assembly fails for multi-module project if webstart-maven-plugin is in use
Robin Roos created MASSEMBLY-658: Summary: Assembly fails for multi-module project if webstart-maven-plugin is in use Key: MASSEMBLY-658 URL: https://jira.codehaus.org/browse/MASSEMBLY-658 Project: Maven 2.x Assembly Plugin Issue Type: Bug Components: dependencySet Affects Versions: 2.4 Environment: Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51: 28+) Maven home: C:\dev\apache-maven-3.0.5\bin\.. Java version: 1.6.0_45, vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\jdk1.6.0_45\jre Default locale: en_GB, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Reporter: Robin Roos Attachments: npe-war-assebmbly.zip The mvn invocation I used is: mvn clean package I attach a simple test case of a multi-module project. If the acme-jnlp module is commented out in the parent POM then the project builds successfully. If the acme-jnlp module is not commented out, then the assembly of acme-dist fails because of a NullPointerException. acme-dist and acme-war to not rely on the artifacts generated by acme-jnlp. The mere fact that the plugin is executed causes the later module assembly to fail. Modules have the following purposes: acme-parent: parent project which contains the module acme-jnlp: create JNLP and ZIP files not used by any other modules acme-war: create a .WAR file acme-dist: use assembly plugin to create a .ZIP containing the .WAR acme-deploy: holds dependencies to other modules, but does nothing else -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-658) Assembly fails for multi-module project if webstart-maven-plugin is in use
[ https://jira.codehaus.org/browse/MASSEMBLY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328194#comment-328194 ] Robin Roos commented on MASSEMBLY-658: -- org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single (default) on project acme-dist: Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver$DefaultFileInfo.isFile(AssemblyProxyArchiver.java:871) at org.apache.maven.plugin.assembly.filter.ComponentsXmlArchiverFileFilter.isSelected(ComponentsXmlArchiverFileFilter.java:193) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.acceptFile(AssemblyProxyArchiver.java:825) at org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.addFile(AssemblyProxyArchiver.java:476) at org.apache.maven.plugin.assembly.archive.task.AddArtifactTask.execute(AddArtifactTask.java:212) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addNormalArtifact(AddDependencySetsTask.java:351) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.addDependencySet(AddDependencySetsTask.java:186) at org.apache.maven.plugin.assembly.archive.task.AddDependencySetsTask.execute(AddDependencySetsTask.java:124) at org.apache.maven.plugin.assembly.archive.phase.DependencySetAssemblyPhase.execute(DependencySetAssemblyPhase.java:76) at org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:183) at org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 20 more > Assembly fails for multi-module project if webstart-maven-plugin is in use > -- > > Key: MASSEMBLY-658 > URL: https://jira.codehaus.org/browse/MASSEMBLY-658 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 > Environment: Apache Maven 3.0.5 > (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51: > 28+) > Maven home: C:\dev\apache-maven-3.0.5\bin\.. > Java version: 1.6.0_45, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_45\jre > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", fa
[jira] (MASSEMBLY-658) Assembly fails for multi-module project if webstart-maven-plugin is in use
[ https://jira.codehaus.org/browse/MASSEMBLY-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robin Roos updated MASSEMBLY-658: - Attachment: output.log Log output > Assembly fails for multi-module project if webstart-maven-plugin is in use > -- > > Key: MASSEMBLY-658 > URL: https://jira.codehaus.org/browse/MASSEMBLY-658 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug > Components: dependencySet >Affects Versions: 2.4 > Environment: Apache Maven 3.0.5 > (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 13:51: > 28+) > Maven home: C:\dev\apache-maven-3.0.5\bin\.. > Java version: 1.6.0_45, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_45\jre > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Robin Roos > Attachments: npe-war-assebmbly.zip, output.log > > > The mvn invocation I used is: > mvn clean package > I attach a simple test case of a multi-module project. If the acme-jnlp > module is commented out in the parent POM then the project builds > successfully. If the acme-jnlp module is not commented out, then the assembly > of acme-dist fails because of a NullPointerException. > acme-dist and acme-war to not rely on the artifacts generated by acme-jnlp. > The mere fact that the plugin is executed causes the later module assembly to > fail. > Modules have the following purposes: > acme-parent: parent project which contains the module > acme-jnlp: create JNLP and ZIP files not used by any other modules > acme-war: create a .WAR file > acme-dist: use assembly plugin to create a .ZIP containing the .WAR > acme-deploy: holds dependencies to other modules, but does nothing else -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1013) Fix typo, forkCount instead of forkMode on fork options examples page
[
https://jira.codehaus.org/browse/SUREFIRE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian updated SUREFIRE-1013:
-
Fix Version/s: 2.16
> Fix typo, forkCount instead of forkMode on fork options examples page
> -
>
> Key: SUREFIRE-1013
> URL: https://jira.codehaus.org/browse/SUREFIRE-1013
> Project: Maven Surefire
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.15
>Reporter: Stevo Slavic
>Assignee: Andreas Gudian
>Priority: Trivial
> Fix For: 2.16
>
>
> In paragraph
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Forked_Test_Execution
> there is sentence:
> {noformat}
> forkMode=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
> Instead it should be
> {noformat}
> forkCount=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1013) Fix typo, forkCount instead of forkMode on fork options examples page
[
https://jira.codehaus.org/browse/SUREFIRE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Gudian closed SUREFIRE-1013.
Resolution: Fixed
Fixed. Thanks for the report! :)
> Fix typo, forkCount instead of forkMode on fork options examples page
> -
>
> Key: SUREFIRE-1013
> URL: https://jira.codehaus.org/browse/SUREFIRE-1013
> Project: Maven Surefire
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.15
>Reporter: Stevo Slavic
>Assignee: Andreas Gudian
>Priority: Trivial
> Fix For: 2.16
>
>
> In paragraph
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Forked_Test_Execution
> there is sentence:
> {noformat}
> forkMode=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
> Instead it should be
> {noformat}
> forkCount=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1012) runOrder doesn't seem to have an effect at all for TestNG tests
[ https://jira.codehaus.org/browse/SUREFIRE-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian reassigned SUREFIRE-1012: Assignee: Andreas Gudian > runOrder doesn't seem to have an effect at all for TestNG tests > --- > > Key: SUREFIRE-1012 > URL: https://jira.codehaus.org/browse/SUREFIRE-1012 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.15 >Reporter: Christoph Kutzinski >Assignee: Andreas Gudian > Attachments: test.zip > > > I've tried different runOrders (random, reversealphabetical) with TestNG, but > none seems to have an effect at all - tests seem always to be run > alphabetically -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-65) Plugin not thread safe (java.util.ConcurrentModificationException)
[
https://jira.codehaus.org/browse/MRRESOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp reassigned MRRESOURCES-65:
--
Assignee: Daniel Kulp
> Plugin not thread safe (java.util.ConcurrentModificationException)
> --
>
> Key: MRRESOURCES-65
> URL: https://jira.codehaus.org/browse/MRRESOURCES-65
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Olivier Lamy
>Assignee: Daniel Kulp
>Priority: Critical
>
> stack trace
> {code}
> Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 13 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
> at java.util.Hashtable.putAll(Hashtable.java:465)
> at
> org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:663)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:997)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:511)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 14 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-68) Support bundling under different classifiers
[ https://jira.codehaus.org/browse/MRRESOURCES-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp closed MRRESOURCES-68. -- Resolution: Fixed Fix Version/s: 1.5 Assignee: Daniel Kulp removed read-only flag > Support bundling under different classifiers > > > Key: MRRESOURCES-68 > URL: https://jira.codehaus.org/browse/MRRESOURCES-68 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Tuomas Kiviaho >Assignee: Daniel Kulp > Fix For: 1.5 > > > Currently it seems to possible to process classifier bundles (test jars for > instance) as well, but bundling is only supported for main artifact. There is > already an outputDirectory parameters but is has been marked as read-only. > Would it possible remove the read-only flag from outputDirectory so that > remote-resources bundling could be used for classified artifacts as well and > not just for main artifact. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-53) use of remote resources plugin breaks ability to use test-jar artifacts
[ https://jira.codehaus.org/browse/MRRESOURCES-53?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp closed MRRESOURCES-53. -- Resolution: Fixed Fix Version/s: 1.5 Assignee: Daniel Kulp Added a new configuration option to allow specifying the scopes used for resolving dependencies. Also, made the default "runtime" instead of "test" in most cases. > use of remote resources plugin breaks ability to use test-jar artifacts > --- > > Key: MRRESOURCES-53 > URL: https://jira.codehaus.org/browse/MRRESOURCES-53 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Scott Carey >Assignee: Daniel Kulp >Priority: Critical > Fix For: 1.5 > > Attachments: project.zip > > > I have a dead simple project configuration that breaks if I inherit from > org.apache:apache . If I disable the remote resources plugin portion, it > works. > The plugin is trying to resolve a test-jar artifact during the compile phase, > but such an artifact does not exist until the test-compile phase. > To reproduce: unpack the project provided. run 'mvn clean compile'. that > will fail. test-compile will work. If you install, then compile will work > because it will find the test-jar in the local repo. You must not have any > related snapshot artifacts in the local repo related to this project to > reproduce. > If you break the inheritance to the apache parent, it will work. Or, you can > override the usage of the remote resources plugin and disable it to get the > project to function. > It seems to work if I assign the plugin to operate in a late phase -- such as > prepare-package. Perhaps all that is required is that the plugin operate in > as late a phase as it can by default? > If it must operate in compile however, it cannot look for dependencies that > are not generated until test-compile such as test-jar types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-58) 'process' goal fails with NPE at the root of a reactor if child modules use version ranges for dependencies
[ https://jira.codehaus.org/browse/MRRESOURCES-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp closed MRRESOURCES-58. -- Resolution: Fixed Fix Version/s: 1.5 Assignee: Daniel Kulp Patch applied. > 'process' goal fails with NPE at the root of a reactor if child modules use > version ranges for dependencies > --- > > Key: MRRESOURCES-58 > URL: https://jira.codehaus.org/browse/MRRESOURCES-58 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.2.1, 1.3 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 17:31:09+) > Java version: 1.6.0_25, vendor: Sun Microsystems Inc. > Default locale: en_GB, platform encoding: UTF-8 > OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" >Reporter: Sergei Ivanov >Assignee: Daniel Kulp > Fix For: 1.5 > > Attachments: test-reactor-version-ranges.zip, > version-ranges-bugfix.patch, version-ranges-bugfix-v2.patch > > > When the maven-remote-resources-plugin:process goal is integrated into the > lifecycle of a parent project in a multi-module reactor build, the goal fails > with an NPE if dependency version ranges are used in the child modules. > Additionally, "runOnlyAtExecutionRoot" option needs to be set to true in > order to recreate the problem. Please see the attached test project that > demonstrates the problem. > Full exception trace is as follows: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process > (process-remote-resources) on project test-parent: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process > (process-remote-resources) on project test-parent: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) > 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) > at > org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > at org.codehaus.classworlds.Launcher.main(Launcher.java:47) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > Caused by: org.apache.maven.plugin.PluginExecutionException: Execution > process-remote-resources of goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2.1:process failed. > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) > at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) >
[jira] (MRRESOURCES-65) Plugin not thread safe (java.util.ConcurrentModificationException)
[
https://jira.codehaus.org/browse/MRRESOURCES-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328210#comment-328210
]
Daniel Kulp commented on MRRESOURCES-65:
I think this is something deeper in the core than the remote-resources.
Either that or it's a problem with RR along with some other plugin.
Basically, as part of creating a project, it copies the System properties into
a new map. It LOOKS like some other plugin someplace is setting a system
property at the same time. No idea how to track that down. Remote-resources
doesn't set any properties.
In any case, this isn't in remote-resources.
> Plugin not thread safe (java.util.ConcurrentModificationException)
> --
>
> Key: MRRESOURCES-65
> URL: https://jira.codehaus.org/browse/MRRESOURCES-65
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Olivier Lamy
>Assignee: Daniel Kulp
>Priority: Critical
>
> stack trace
> {code}
> Execution default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
> 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.plugin.PluginExecutionException: Execution
> default of goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.3:process failed.
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 13 more
> Caused by: java.util.ConcurrentModificationException
> at java.util.Hashtable$Enumerator.next(Hashtable.java:1031)
> at java.util.Hashtable.putAll(Hashtable.java:465)
> at
> org.apache.maven.project.DefaultProjectBuildingRequest.setSystemProperties(DefaultProjectBuildingRequest.java:166)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.toRequest(DefaultMavenProjectBuilder.java:79)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:229)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251)
> at
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:258)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.getProjects(ProcessRemoteResourcesMojo.java:663)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.configureVelocityContext(ProcessRemoteResourcesMojo.java:997)
> at
> org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:511)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> ... 14 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-67) Multiple Executions unsafe
[
https://jira.codehaus.org/browse/MRRESOURCES-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328211#comment-328211
]
Daniel Kulp commented on MRRESOURCES-67:
You don't specify what version of Maven you are using. Make sure you are using
Maven 3.0.5 and see if it's still a problem.
Additionally, can you try with the latest 1.5-SNAPSHOT version of
remote-resources? I've completely changes how the velocity engine is setup and
resources grabbed to try and make sure they are all unique per execution.
> Multiple Executions unsafe
> --
>
> Key: MRRESOURCES-67
> URL: https://jira.codehaus.org/browse/MRRESOURCES-67
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.4
> Environment: Mac & Windows
> Java 1.6 & 1.7
>Reporter: John Patrick
>
> When using executions, the resourceBundles in the 1st are using in all
> subsequent executions.
> Have a simple jar(s) which contain
> src/main/resources/WEB-INF/classes/client.properties
> Those are built in project-web-client-X and project-web-client-Y. The jar
> contain the correct client.properties.
> Within the war pom I define.
> org.apache.maven.pluginsmaven-remote-resoruces-plugin
>
>
> client-X
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-X
>
>
> ${project.groupId}:project-web-client-X:${project.version}
>
>
>
>
> client-Y
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-Y
>
>
> ${project.groupId}:project-web-client-Y:${project.version}
>
>
>
>
> client-Z
> process-resources
>
> process
>
>
>
> ${project.build.directory/${project.build.finalName}-client-Z
>
>
> ${project.groupId}:project-web-client-Z:${project.version}
>
>
>
>
> [...]
> I do a clean install and I get client-X client.properties in the following
> locations. Not the one i'm expecting using the resource bundles above.
> ${project.build.directory/${project.build.finalName}-client-X/WEB-INF/classes/client.properties
> ${project.build.directory/${project.build.finalName}-client-Y/WEB-INF/classes/client.properties
> ${project.build.directory/${project.build.finalName}-client-Z/WEB-INF/classes/client.properties
> John
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRRESOURCES-62) test-jar classifier fails in multi-module projects
[
https://jira.codehaus.org/browse/MRRESOURCES-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp closed MRRESOURCES-62.
--
Resolution: Fixed
Fix Version/s: 1.5
Assignee: Daniel Kulp
> test-jar classifier fails in multi-module projects
> --
>
> Key: MRRESOURCES-62
> URL: https://jira.codehaus.org/browse/MRRESOURCES-62
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Jeff Maxwell
>Assignee: Daniel Kulp
>Priority: Critical
> Fix For: 1.5
>
>
> If a resourceBundle is a test-jar of a sibling project the process step will
> attempt to pull resources from /classes
> {code}
> @SuppressWarnings( "unchecked" )
> private List downloadBundles( List bundles )
> throws MojoExecutionException
> {
> List bundleArtifacts = new ArrayList();
> try
> {
> for ( String artifactDescriptor : bundles )
> {
> // groupId:artifactId:version[:type[:classifier]]
> String[] s = artifactDescriptor.split( ":" );
> File artifactFile = null;
> //check if the artifact is part of the reactor
> if ( mavenSession != null )
> {
> List list =
> mavenSession.getSortedProjects();
> for ( MavenProject p : list )
> {
> if ( s[0].equals( p.getGroupId() ) && s[1].equals(
> p.getArtifactId() ) && s[2].equals(
> p.getVersion() ) )
> {
> // FIXME Needs to depend on classifier
> // Should be like:
> // if("test-jar".equals(type))
> //{
> // artifactFile = new File(
> p.getBuild().testOutputDirectory());
> // }
> // else
> // {
>artifactFile = new File(
> p.getBuild().getOutputDirectory() );
> // }
> }
> }
> }
> if ( artifactFile == null || !artifactFile.exists() )
> {
> String type = ( s.length >= 4 ? s[3] : "jar" );
> String classifier = ( s.length == 5 ? s[4] : null );
> Artifact artifact =
> artifactFactory.createDependencyArtifact( s[0], s[1],
> VersionRange.createFromVersion( s[2] ),
> type,
> classifier, Artifact.SCOPE_RUNTIME );
> artifactResolver.resolve( artifact,
> remoteArtifactRepositories, localRepository );
> artifactFile = artifact.getFile();
> }
> bundleArtifacts.add( artifactFile );
> }
> }
> catch ( ArtifactResolutionException e )
> {
> throw new MojoExecutionException( "Error downloading resources
> archive.", e );
> }
> catch ( ArtifactNotFoundException e )
> {
> throw new MojoExecutionException( "Resources archive cannot be
> found.", e );
> }
> return bundleArtifacts;
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-1013) Fix typo, forkCount instead of forkMode on fork options examples page
[
https://jira.codehaus.org/browse/SUREFIRE-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328215#comment-328215
]
Stevo Slavic commented on SUREFIRE-1013:
Thank you [~agudian] for quick fix!
> Fix typo, forkCount instead of forkMode on fork options examples page
> -
>
> Key: SUREFIRE-1013
> URL: https://jira.codehaus.org/browse/SUREFIRE-1013
> Project: Maven Surefire
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.15
>Reporter: Stevo Slavic
>Assignee: Andreas Gudian
>Priority: Trivial
> Fix For: 2.16
>
>
> In paragraph
> http://maven.apache.org/surefire/maven-surefire-plugin/examples/fork-options-and-parallel-execution.html#Forked_Test_Execution
> there is sentence:
> {noformat}
> forkMode=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
> Instead it should be
> {noformat}
> forkCount=1/reuseForks=false executes each test class in its own JVM process,
> one after another.
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
