[jira] (MNG-4706) Multithreaded building can create bad files for downloaded artifacts in local repository
[ https://jira.codehaus.org/browse/MNG-4706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346723#comment-346723 ] Tomas Kolda edited comment on MNG-4706 at 5/20/14 1:59 AM: --- We were facing exactly same issue with 3.1.1. The problem is that Aether has empty default implementation of org.eclipse.aether.SyncContext that does not protect local repository at all. This is what happens: 1. Two modules depends on the same dependency 2. Resolution starts download process in more threads even if SyncContext.acquire was called for that artifact 3. The first thread creates the file using MOVE (temporary file-final file) 4. Second thread want to create the file MOVE (temporary file-final file), but it fails (move does not support overwrite). As a fallback it simply do copy over. 5. First thread fails, because it gets invalid data (half of jar file, etc.) This must not happen if Maven is declaring parallel build support. There are some projects like https://github.com/grdryn/tesla-concurrent-localrepo that introduce file locking using lockfile or https://github.com/evanchsa/maven-parallel-resolver that locks resolver.I am not sure if it has some impact on performance due to I/O (create/delete files). I wrote very simple (one class) memory only locking that works too and does not depend on anything else. It does not work for multiple processes, but it works in similar way. Maven should have at least some basic (one process only) implementation of this SyncContext so that users will not need to update Maven instalation using lib/ext. was (Author: koldat): We were facing exactly same issue with 3.1.1. The problem is that Aether has empty default implementation of org.eclipse.aether.SyncContext that does not protect local repository at all. This is what happens: 1. Two modules depends on the same dependency 2. Resolution starts download process in more threads even if SyncContext.acquire was called for that artifact 3. The first thread creates the file using MOVE (temporary file-final file) 4. Second thread want to create the file MOVE (temporary file-final file), but it fails (move does not support overwrite). As a fallback it simply do copy over. 5. First thread fails, because it gets invalid data (half of jar file, etc.) This must not happen if Maven is declaring parallel build support. There are some projects like https://github.com/grdryn/tesla-concurrent-localrepo that introduce file locking using lockfile.I am not sure if it has some impact on performance due to I/O (create/delete files). I wrote very simple (one class) memory only locking that works too and does not depend on anything else. It does not work for multiple processes, but it works in similar way. Maven should have at least some basic (one process only) implementation of this SyncContext so that users will not need to update Maven instalation using lib/ext. Multithreaded building can create bad files for downloaded artifacts in local repository Key: MNG-4706 URL: https://jira.codehaus.org/browse/MNG-4706 Project: Maven 2 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold Fix For: Issues to be reviewed for 4.x Within a parallel build, modules A and B can start at the same time and decide at the same time that they need to download artifact X. Since X is not available locally, both can start download of X. Both will download X and both will try to write the file for X to disk. On Windows platforms, one of them can fail with file locking problems. On Unixes the contents of the written file can be non-deterministic. This issue is related to MNG-2802 in the sense that it can create a corrupted artifact file in the local repository, and it can happen to ANY file written. But as opposed to MNG-2802 the synhronization needed to fix this issue is basically only within a single running maven process, so regular java mechanisms can apply, whereas MNG-2802 probably needs to use a totally different solution space. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-335) announcement-mail broken when NOT using the announcementFile parameter
[
https://jira.codehaus.org/browse/MCHANGES-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346752#comment-346752
]
Guillaume Husta commented on MCHANGES-335:
--
OK thanks for your explanations.
So I've chosen the option #2, with adding something like that in my config :
{code:xml}
!-- Property to define if plugin version = 2.10 --
announcementFilechanges-${project.artifactId}.txt/announcementFile
{code}
announcement-mail broken when NOT using the announcementFile parameter
--
Key: MCHANGES-335
URL: https://jira.codehaus.org/browse/MCHANGES-335
Project: Maven Changes Plugin
Issue Type: Bug
Components: announcement
Affects Versions: 2.10
Reporter: Guillaume Husta
Attachments: test-changes-335.zip
When using a custom template to generate an announcement, the goal
_announcement-mail_ will fail if :
* I provide the parameters _template_ (other than announcement.vm) and
_templateDirectory_
* and I don't provide the parameter _announcementFile_
Trace :
bq. [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-changes-plugin:2.10:announcement-mail
(default-cli) on project test-changes-sendmail: Announcement file
D:\Projets\Workspace_projets_java\test-changes-sendmail\target\announcement\announcement.vm
not found... - [Help 1]
This is a *regression* : it worked with version 2.9
Related to MCHANGES-280
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (ARCHETYPE-308) Should ask input for requiredProperty with defaultValue
[ https://jira.codehaus.org/browse/ARCHETYPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346753#comment-346753 ] Gregory Amerson commented on ARCHETYPE-308: --- Ping? Should ask input for requiredProperty with defaultValue --- Key: ARCHETYPE-308 URL: https://jira.codehaus.org/browse/ARCHETYPE-308 Project: Maven Archetype Issue Type: Bug Reporter: Grégory Joseph Attachments: ARCHETYPE-200.patch It seems that if a requiredProperty is defined with a defaultValue, the generate mojo does not ask user input. In my opinion it should, just like it does it for the version. DefaultArchetypeFactory lines 156-168 seem to be the culprit and I'll attach a patch that might fix this. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2852) process-test-classes phase is run even when maven.test.skip is called
[
https://jira.codehaus.org/browse/MNG-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346781#comment-346781
]
Tomasz Bartczak commented on MNG-2852:
--
the same is for test-compile and as I presume all other phases.
however this workaround works as well for exec and assembly plugin
process-test-classes phase is run even when maven.test.skip is called
-
Key: MNG-2852
URL: https://jira.codehaus.org/browse/MNG-2852
Project: Maven 2 3
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.5
Reporter: Dan Diephouse
Fix For: Issues to be reviewed for 3.x
I'm have some bytecode processing which occurs in the
{{process-test-classes}} phase. When I skip the tests, it still tries to run
my ant task:
{noformat}
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [antrun:run {execution: default}]
[echo] Running Jibx Ant task
{noformat}
My task definition looks like this:
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseprocess-test-classes/phase
goals
goalrun/goal
/goals
configuration
tasks
echoRunning Jibx Ant task/echo
taskdef classname=org.jibx.binding.ant.CompileTask
classpathref=maven.test.classpath name=jibx /
jibx verbose=true
binding=${basedir}/src/jibx/binding.xml
classpathset dir=${basedir}/target/test-classes /
/jibx
/tasks
/configuration
/execution
/executions
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1077) NPE problem will happen if you set testng status to fail at afterInvocation method
[ https://jira.codehaus.org/browse/SUREFIRE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346791#comment-346791 ] Andreas Gudian commented on SUREFIRE-1077: -- Let's schedule this for a fix in the next release... Shouldn't be too hard... :) NPE problem will happen if you set testng status to fail at afterInvocation method -- Key: SUREFIRE-1077 URL: https://jira.codehaus.org/browse/SUREFIRE-1077 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.13, 2.14, 2.15, 2.16, 2.17 Environment: Maven 3.1.1, TestNG (Try different version), Maven suirefire plugin 2.11~2.17 Reporter: tim wu Fix For: 2.18 Attachments: target.zip In our test program, we have some soft assert, which require us set the test result to false at afterInovcation (IInvokedMethodListener) method, after we did that, surefire plugin will throw a NPE exception, the stacktrace looks like this: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.61 sec FAILURE! test1(com.surefire.SimpleTest) Time elapsed: 0.044 sec FAILURE! java.lang.NullPointerException: null at org.apache.maven.surefire.report.SmartStackTraceParser.init(SmartStackTraceParser.java:56) at org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:60) at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328) at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312) at org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258) at org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:105) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1895) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1879) at org.testng.internal.Invoker.invokeMethod(Invoker.java:778) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) at org.testng.SuiteRunner.run(SuiteRunner.java:254) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) at org.testng.TestNG.run(TestNG.java:1057) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:126) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) I will attach a simple project to reproduce this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1077) NPE problem will happen if you set testng status to fail at afterInvocation method
[ https://jira.codehaus.org/browse/SUREFIRE-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Gudian updated SUREFIRE-1077: - Fix Version/s: 2.18 NPE problem will happen if you set testng status to fail at afterInvocation method -- Key: SUREFIRE-1077 URL: https://jira.codehaus.org/browse/SUREFIRE-1077 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.13, 2.14, 2.15, 2.16, 2.17 Environment: Maven 3.1.1, TestNG (Try different version), Maven suirefire plugin 2.11~2.17 Reporter: tim wu Fix For: 2.18 Attachments: target.zip In our test program, we have some soft assert, which require us set the test result to false at afterInovcation (IInvokedMethodListener) method, after we did that, surefire plugin will throw a NPE exception, the stacktrace looks like this: Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.61 sec FAILURE! test1(com.surefire.SimpleTest) Time elapsed: 0.044 sec FAILURE! java.lang.NullPointerException: null at org.apache.maven.surefire.report.SmartStackTraceParser.init(SmartStackTraceParser.java:56) at org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:60) at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:328) at org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:312) at org.apache.maven.surefire.booter.ForkingRunListener.toString(ForkingRunListener.java:258) at org.apache.maven.surefire.booter.ForkingRunListener.testFailed(ForkingRunListener.java:137) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:105) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1895) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1879) at org.testng.internal.Invoker.invokeMethod(Invoker.java:778) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) at org.testng.TestRunner.privateRun(TestRunner.java:767) at org.testng.TestRunner.run(TestRunner.java:617) at org.testng.SuiteRunner.runTest(SuiteRunner.java:348) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305) at org.testng.SuiteRunner.run(SuiteRunner.java:254) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224) at org.testng.TestNG.runSuitesLocally(TestNG.java:1149) at org.testng.TestNG.run(TestNG.java:1057) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeSingleClass(TestNGDirectoryTestSuite.java:126) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:110) at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:117) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray2(ReflectionUtils.java:208) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:158) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:95) I will attach a simple project to reproduce this problem. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-336) Create a method in the DependencyGraphBuilder that accepts the reactor projects and resolves dependencies from within the reactor
[ https://jira.codehaus.org/browse/MSHARED-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MSHARED-336: -- Description: https://github.com/apache/maven-shared/pull/5 https://github.com/apache/maven-shared/pull/6 was:https://github.com/apache/maven-shared/pull/5 Create a method in the DependencyGraphBuilder that accepts the reactor projects and resolves dependencies from within the reactor - Key: MSHARED-336 URL: https://jira.codehaus.org/browse/MSHARED-336 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-tree Reporter: Jason van Zyl Assignee: Jason van Zyl https://github.com/apache/maven-shared/pull/5 https://github.com/apache/maven-shared/pull/6 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5613) NPE error when building a reactor with duplicated artifacts
[
https://jira.codehaus.org/browse/MNG-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl reassigned MNG-5613:
--
Assignee: Jason van Zyl
NPE error when building a reactor with duplicated artifacts
---
Key: MNG-5613
URL: https://jira.codehaus.org/browse/MNG-5613
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Dominique Broeglin
Assignee: Jason van Zyl
Attachments: foo.zip
Using v3.2.1 when building a malformed project containing a duplicated
groupId:artifactId I got this rather unhelpful error:
{code}
[ERROR] Internal error: java.lang.NullPointerException - [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.NullPointerException
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
... 11 more
{code}
The more helpful error should have been:
{code}
org.apache.maven.project.DuplicateProjectException: Project
'com.foo.bar:foo-bar:2.15.0' is duplicated in the reactor
at org.apache.maven.project.ProjectSorter.init(ProjectSorter.java:93)
at
org.apache.maven.DefaultProjectDependencyGraph.init(DefaultProjectDependencyGraph.java:53)
at
org.apache.maven.DefaultMaven.createProjectDependencyGraph(DefaultMaven.java:819)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:268)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5613) NPE error when building a reactor with duplicated artifacts
[
https://jira.codehaus.org/browse/MNG-5613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-5613.
--
Resolution: Fixed
Committed on bef7fac6e3495dae57a44e6a5902afd89c74b196
Submitted by: Sebastian Le Merdy
From: https://github.com/apache/maven/pull/13
NPE error when building a reactor with duplicated artifacts
---
Key: MNG-5613
URL: https://jira.codehaus.org/browse/MNG-5613
Project: Maven 2 3
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Dominique Broeglin
Assignee: Jason van Zyl
Attachments: foo.zip
Using v3.2.1 when building a malformed project containing a duplicated
groupId:artifactId I got this rather unhelpful error:
{code}
[ERROR] Internal error: java.lang.NullPointerException - [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.NullPointerException
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:270)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
... 11 more
{code}
The more helpful error should have been:
{code}
org.apache.maven.project.DuplicateProjectException: Project
'com.foo.bar:foo-bar:2.15.0' is duplicated in the reactor
at org.apache.maven.project.ProjectSorter.init(ProjectSorter.java:93)
at
org.apache.maven.DefaultProjectDependencyGraph.init(DefaultProjectDependencyGraph.java:53)
at
org.apache.maven.DefaultMaven.createProjectDependencyGraph(DefaultMaven.java:819)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:268)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-4226.
--
Resolution: Fixed
Assignee: Jason van Zyl
Better detection of JAVA_HOME on Apple Mac OS X
---
Key: MNG-4226
URL: https://jira.codehaus.org/browse/MNG-4226
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Reporter: Alin Dreghiciu
Assignee: Jason van Zyl
Fix For: Issues to be reviewed for 3.x
Attachments: 0001-MNG-4226-Detect-JAVA_HOME-on-newer-Mac-OS-X.patch,
MNG-4226-apache-maven.patch
On mac JAVA_HOME is detected by using the following code:
{code}
if [ -z $JAVA_VERSION ] ; then
JAVA_VERSION=CurrentJDK
else
echo Using Java version: $JAVA_VERSION
fi
if [ -z $JAVA_HOME ] ; then
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
fi
{code}
But this does not work in collaboration with Using Java preferences to
change the actual java version to use as CurrentJDK does not change once
you update the java applications order.
There is an alternative (at least on Leopard) for determining current java
home that is based on Java Preferences by using an apple provided script. So,
as a replacement fo rthe code above the following could be used.
{code}
if [ -z $JAVA_HOME ] ; then
JAVA_HOME=`/usr/libexec/java_home | tail -1`
fi
{code}
Could also be taht this is teh first attempt and if fails use the current way
of determining home.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-4226) Better detection of JAVA_HOME on Apple Mac OS X
[
https://jira.codehaus.org/browse/MNG-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=346797#comment-346797
]
Jason van Zyl commented on MNG-4226:
Committed on 65863e0a28298b6d95bfbbf7cc28953f6ba91f93
Submitted by: Christopher Tubbs ctubb...@apache.org
https://github.com/apache/maven/pull/11
Better detection of JAVA_HOME on Apple Mac OS X
---
Key: MNG-4226
URL: https://jira.codehaus.org/browse/MNG-4226
Project: Maven 2 3
Issue Type: Improvement
Components: Command Line
Reporter: Alin Dreghiciu
Assignee: Jason van Zyl
Fix For: Issues to be reviewed for 3.x
Attachments: 0001-MNG-4226-Detect-JAVA_HOME-on-newer-Mac-OS-X.patch,
MNG-4226-apache-maven.patch
On mac JAVA_HOME is detected by using the following code:
{code}
if [ -z $JAVA_VERSION ] ; then
JAVA_VERSION=CurrentJDK
else
echo Using Java version: $JAVA_VERSION
fi
if [ -z $JAVA_HOME ] ; then
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
fi
{code}
But this does not work in collaboration with Using Java preferences to
change the actual java version to use as CurrentJDK does not change once
you update the java applications order.
There is an alternative (at least on Leopard) for determining current java
home that is based on Java Preferences by using an apple provided script. So,
as a replacement fo rthe code above the following could be used.
{code}
if [ -z $JAVA_HOME ] ; then
JAVA_HOME=`/usr/libexec/java_home | tail -1`
fi
{code}
Could also be taht this is teh first attempt and if fails use the current way
of determining home.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-230) ConcurrentModificationException in FileResourceLoader.getResource
Andrew Gaul created MCHECKSTYLE-230:
---
Summary: ConcurrentModificationException in
FileResourceLoader.getResource
Key: MCHECKSTYLE-230
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-230
Project: Maven Checkstyle Plugin
Issue Type: Bug
Affects Versions: 2.12.1
Reporter: Andrew Gaul
I encountered a ConcurrentModificationException when running:
{noformat}
mvn checkstyle:checkstyle -e -T 4
{noformat}
against the jclouds code base:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle
(default-cli) on project ultradns-ws: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle failed.
ConcurrentModificationException - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle
(default-cli) on project ultradns-ws: Execution default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
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:169)
at
org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:165)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.12.1:checkstyle failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:115)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 11 more
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:859)
at java.util.ArrayList$Itr.next(ArrayList.java:831)
at
org.codehaus.plexus.resource.loader.FileResourceLoader.getResource(FileResourceLoader.java:56)
at
org.apache.maven.plugin.checkstyle.resource.LicenseResourceManager.getResource(LicenseResourceManager.java:70)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getOverridingProperties(DefaultCheckstyleExecutor.java:460)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:299)
at
org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:185)
at
org.apache.maven.plugin.checkstyle.AbstractCheckstyleReport.executeReport(AbstractCheckstyleReport.java:488)
at
org.apache.maven.plugin.checkstyle.CheckstyleReport.executeReport(CheckstyleReport.java:156)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:196)
at
org.apache.maven.reporting.AbstractMavenReport.execute(AbstractMavenReport.java:104)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
... 12 more
{noformat}
The underlying problem appears to be within plexus resources and I have opened
an issue and submitted a possible fix:
http://jira.codehaus.org/browse/PLXCOMP-237
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
