[jira] (SUREFIRE-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=301979#comment-301979 ] Adrian Nistor edited comment on SUREFIRE-879 at 6/28/12 5:52 AM: - I pushed a fix to github and made a pull request: https://github.com/apache/maven-surefire/pull/6 Thanks was (Author: anistor): I pushed a fix to github and made a pull request: https://github.com/apache/maven-surefire/pull/5 Thanks > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > > Key: SUREFIRE-879 > URL: https://jira.codehaus.org/browse/SUREFIRE-879 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Java version: 1.6.0_32 > Maven version: 3.0.4 > maven-surefire-report-plugin: 2.12 > TestNG: 5.14.10 >Reporter: Adrian Nistor > Attachments: surefire-879-bug.zip > > > I'm running TestNG tests in parallel and get this exception > ConcurrentModificationException. > My quick analysis is that at the end of the test the method > TestSetRunListener.getAsString is accessing the list of captured output while > another thread (a stray thread spawned by the test or a completely different > concurrent test) generates some more console output causing an append to the > list which results in ConcurrentModificationException. > To fix this we need to ensure getAsString accesses the list atomically. A > possible solution is to copy/clone the list before iterating over it. > Here is the stakctrace I get. > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) > at java.util.AbstractList$Itr.next(AbstractList.java:343) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) > at > org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at > org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > 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) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-728) The commit message for release:branch is wrong
[ https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302063#comment-302063 ] Grégory Joseph commented on MRELEASE-728: - Granted, I don't know much about the intricacies of the plugin, but @joewalton, could you summarize how that change affects the commit message which is used ? The one used by SVN as per your previous comment isn't exactly correct either - or at least it's not what the reported was wishing for, i.e a message that clearly states this is a *new branch*. > The commit message for release:branch is wrong > -- > > Key: MRELEASE-728 > URL: https://jira.codehaus.org/browse/MRELEASE-728 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch, Git >Affects Versions: 2.2.1 > Environment: git 1.7.5.4 >Reporter: Adrien Ragot >Assignee: Robert Scholte > Fix For: 2.3 > > > Using Git, when you do mvn release:branch -DbranchName=xxx, > the commit message for master is "[maven-release-plugin] prepare release xxx". > The right commit message should be "[maven-release-plugin] prepare branch > xxx", like for Svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-151) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MDEPLOY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MDEPLOY-151: Assignee: Olivier Lamy > use maven-plugin-tools' java 5 annotations > -- > > Key: MDEPLOY-151 > URL: https://jira.codehaus.org/browse/MDEPLOY-151 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Task >Reporter: Herve Boutemy >Assignee: Olivier Lamy > Attachments: MDEPLOY-151.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEPLOY-151) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MDEPLOY-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MDEPLOY-151. Resolution: Fixed Fix Version/s: 2.8 patch applied. Thanks! > use maven-plugin-tools' java 5 annotations > -- > > Key: MDEPLOY-151 > URL: https://jira.codehaus.org/browse/MDEPLOY-151 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: Task >Reporter: Herve Boutemy >Assignee: Olivier Lamy > Fix For: 2.8 > > Attachments: MDEPLOY-151.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-171) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MCOMPILER-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCOMPILER-171. -- Resolution: Fixed Fix Version/s: 2.6 Assignee: Olivier Lamy > use maven-plugin-tools' java 5 annotations > -- > > Key: MCOMPILER-171 > URL: https://jira.codehaus.org/browse/MCOMPILER-171 > Project: Maven 2.x Compiler Plugin > Issue Type: Task >Affects Versions: 2.4 >Reporter: Herve Boutemy >Assignee: Olivier Lamy > Fix For: 2.6 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCLEAN-51) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MCLEAN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MCLEAN-51. -- Resolution: Duplicate Assignee: Olivier Lamy > use maven-plugin-tools' java 5 annotations > -- > > Key: MCLEAN-51 > URL: https://jira.codehaus.org/browse/MCLEAN-51 > Project: Maven 2.x Clean Plugin > Issue Type: Task >Reporter: Herve Boutemy >Assignee: Olivier Lamy > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-88) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MINSTALL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reassigned MINSTALL-88: Assignee: Olivier Lamy > use maven-plugin-tools' java 5 annotations > -- > > Key: MINSTALL-88 > URL: https://jira.codehaus.org/browse/MINSTALL-88 > Project: Maven 2.x Install Plugin > Issue Type: Task >Affects Versions: 2.3.1 >Reporter: Herve Boutemy >Assignee: Olivier Lamy > Attachments: MINSTALL-88.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-88) use maven-plugin-tools' java 5 annotations
[ https://jira.codehaus.org/browse/MINSTALL-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MINSTALL-88. Resolution: Fixed Fix Version/s: 2.4 Patch applied. Thanks! > use maven-plugin-tools' java 5 annotations > -- > > Key: MINSTALL-88 > URL: https://jira.codehaus.org/browse/MINSTALL-88 > Project: Maven 2.x Install Plugin > Issue Type: Task >Affects Versions: 2.3.1 >Reporter: Herve Boutemy >Assignee: Olivier Lamy > Fix For: 2.4 > > Attachments: MINSTALL-88.diff > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated SUREFIRE-879: --- Description: I'm running TestNG tests in parallel and get this exception ConcurrentModificationException. My quick analysis is that at the end of the test the method TestSetRunListener.getAsString is accessing the list of captured output while another thread (a stray thread spawned by the test or a completely different concurrent test) generates some more console output causing an append to the list which results in ConcurrentModificationException. To fix this we need to ensure getAsString accesses the list atomically. A possible solution is to copy/clone the list before iterating over it. Here is the stakctrace I get. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) at org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) 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) was: I'm running TestNG tests in parallel and get this exception ConcurrentModificationException. My quick analysis is that at the end of the test the method TestSetRunListener.getAsString is accessing the list of captured output while another thread (a stray thread spawned by the test or a completely different concurrent test) generates some more console output causing an append to the list which results in ConcurrentModificationException. To fix this we need to ensure getAsString accesses the list atomically. A possible solution is to copy/clone the list before iterating over it. Here is the stakctrace I get. java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) at org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) at org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) at org.testng.TestRunner.runWorkers(TestRunner.java:1147) at org.testng.TestRunner.privateRun(TestRunner.java:749) at org.testng.TestRunner.run(TestRunner.java:600) at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) 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) Fix Version/s: 2.13 Assignee: Paul Gier > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > >
[jira] (SUREFIRE-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed SUREFIRE-879. -- Resolution: Fixed Merged the patch to the main svn repo, thanks! http://svn.apache.org/viewvc?view=revision&revision=1355045 > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > > Key: SUREFIRE-879 > URL: https://jira.codehaus.org/browse/SUREFIRE-879 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Java version: 1.6.0_32 > Maven version: 3.0.4 > maven-surefire-report-plugin: 2.12 > TestNG: 5.14.10 >Reporter: Adrian Nistor >Assignee: Paul Gier > Fix For: 2.13 > > Attachments: surefire-879-bug.zip > > > I'm running TestNG tests in parallel and get this exception > ConcurrentModificationException. > My quick analysis is that at the end of the test the method > TestSetRunListener.getAsString is accessing the list of captured output while > another thread (a stray thread spawned by the test or a completely different > concurrent test) generates some more console output causing an append to the > list which results in ConcurrentModificationException. > To fix this we need to ensure getAsString accesses the list atomically. A > possible solution is to copy/clone the list before iterating over it. > Here is the stakctrace I get. > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) > at java.util.AbstractList$Itr.next(AbstractList.java:343) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) > at > org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at > org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > 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) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302089#comment-302089 ] William Handy commented on MNG-5255: Having the same problem, in my case it is the jboss-interceptors-api_1.1_spec artifact. My war project has dependencies on cdi-api v 1.0-SP4 and jboss-as-web v 7.0.2.Final, both as provided. Those two artifacts have dependencies on the interceptors api artifact with versions 1.0.0.Beta1 and 1.0.0.Final so maybe resolving the conflict in the versions is interfering with the provided transitivity logic? > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302089#comment-302089 ] William Handy edited comment on MNG-5255 at 6/28/12 10:41 AM: -- Having the same problem, in my case it is the jboss-interceptors-api_1.1_spec artifact. My war project has dependencies on cdi-api v 1.0-SP4 and jboss-as-web v 7.0.2.Final, both as provided. Those two artifacts have dependencies on the interceptors api artifact with versions 1.0.0.Beta1 and 1.0.0.Final so maybe resolving the conflict in the versions is interfering with the provided transitivity logic? I should add my version is 3.0.4/1.1.0.20120529-1956 (embedded with m2eclipse) was (Author: wdhandy): Having the same problem, in my case it is the jboss-interceptors-api_1.1_spec artifact. My war project has dependencies on cdi-api v 1.0-SP4 and jboss-as-web v 7.0.2.Final, both as provided. Those two artifacts have dependencies on the interceptors api artifact with versions 1.0.0.Beta1 and 1.0.0.Final so maybe resolving the conflict in the versions is interfering with the provided transitivity logic? > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-879) maven-surefire-report-plugin fails some times with ConcurrentModificationException when running parallel TestNG
[ https://jira.codehaus.org/browse/SUREFIRE-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302091#comment-302091 ] Adrian Nistor commented on SUREFIRE-879: Great! Thanks > maven-surefire-report-plugin fails some times with > ConcurrentModificationException when running parallel TestNG > --- > > Key: SUREFIRE-879 > URL: https://jira.codehaus.org/browse/SUREFIRE-879 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.12 > Environment: Java version: 1.6.0_32 > Maven version: 3.0.4 > maven-surefire-report-plugin: 2.12 > TestNG: 5.14.10 >Reporter: Adrian Nistor >Assignee: Paul Gier > Fix For: 2.13 > > Attachments: surefire-879-bug.zip > > > I'm running TestNG tests in parallel and get this exception > ConcurrentModificationException. > My quick analysis is that at the end of the test the method > TestSetRunListener.getAsString is accessing the list of captured output while > another thread (a stray thread spawned by the test or a completely different > concurrent test) generates some more console output causing an append to the > list which results in ConcurrentModificationException. > To fix this we need to ensure getAsString accesses the list atomically. A > possible solution is to copy/clone the list before iterating over it. > Here is the stakctrace I get. > java.util.ConcurrentModificationException > at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) > at java.util.AbstractList$Itr.next(AbstractList.java:343) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:209) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testFailed(TestSetRunListener.java:168) > at > org.apache.maven.surefire.testng.TestNGReporter.onTestFailure(TestNGReporter.java:104) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1796) > at org.testng.internal.Invoker.runTestListeners(Invoker.java:1780) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:749) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at > org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > 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) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302093#comment-302093 ] Rakesh commented on MNG-5255: - It is very clear. It is a major bug. Once you declare a dependency as provided all its transitive dependencies are upgraded to the same scope and they should not end up in the final artifact. It works perfectly fine with Maven 2 versions. > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-618) use maven-plugin-tools' java 5 annotations
[
https://jira.codehaus.org/browse/MASSEMBLY-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302095#comment-302095
]
Robert Scholte commented on MASSEMBLY-618:
--
{quote}@parameter expression="$\{project.build.directory\}/assembly/work"{quote}
This was wrong and should have been a {{default-value}}.
Now that we use {{property}} instead of {{expression}} the difference should
finally be clear.
> use maven-plugin-tools' java 5 annotations
> --
>
> Key: MASSEMBLY-618
> URL: https://jira.codehaus.org/browse/MASSEMBLY-618
> Project: Maven 2.x Assembly Plugin
> Issue Type: Task
>Affects Versions: 2.3
>Reporter: Tony Chemit
> Attachments: MASSEMBLY-618.diff
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSHADE-125) artifact inclusion filter fail with maven assembly plugin
grhwood created MSHADE-125: -- Summary: artifact inclusion filter fail with maven assembly plugin Key: MSHADE-125 URL: https://jira.codehaus.org/browse/MSHADE-125 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.7 Reporter: grhwood Attachments: xp.maven-assembly.zip After upgrading from maven shade plugin 1.6 to 1.7, my build is failed. Maven shade plugin 1.7 causes the following error with maven assembly plugin: "The following patterns were never triggered in this artifact inclusion filter" The attached file is the sample that reproduce this error. Please run it with mvn clean package -P1.6 or mvn clean package -P1.7 Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302100#comment-302100 ] Joerg Schaible commented on MNG-5255: - Unfortunately it is no *that* clear. Actually we're using the jboss-interceptors-api_1.1_spec also, but do not have this effect. So, it is not clear, what triggers the erroneous behavior. > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302102#comment-302102 ] William Handy commented on MNG-5255: Turns out the m2eclipse dependency hierarchy view was just giving me bad information. It's possible that there is a bug in the maven hierarchy output (which I assume drives the eclipse view) but in my case, I had an errant compile-scoped dependency. > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302104#comment-302104 ] Rakesh commented on MNG-5255: - so how come it works fine with Maven 2.2.1 ? It means there is something wrong with the newer versions dependency resolution mechanism :) . That *strong*erroneous *strong* behavior appears with newer versions of Maven it is clear :) > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302104#comment-302104 ] Rakesh edited comment on MNG-5255 at 6/28/12 1:19 PM: -- so how come it works fine with Maven 2.2.1 ? It means there is something wrong with the newer versions dependency resolution mechanism :) . That *strong* erroneous behavior appears with newer versions of Maven it is clear :) was (Author: rkand4): so how come it works fine with Maven 2.2.1 ? It means there is something wrong with the newer versions dependency resolution mechanism :) . That *strong*erroneous *strong* behavior appears with newer versions of Maven it is clear :) > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5255) Dependency with 'provided' scope has its transitive dependency included in final artifact
[ https://jira.codehaus.org/browse/MNG-5255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302104#comment-302104 ] Rakesh edited comment on MNG-5255 at 6/28/12 1:19 PM: -- so how come it works fine with Maven 2.2.1 ? It means there is something wrong with the newer versions dependency resolution mechanism :) . That erroneous behavior appears with newer versions of Maven it is clear :) was (Author: rkand4): so how come it works fine with Maven 2.2.1 ? It means there is something wrong with the newer versions dependency resolution mechanism :) . That *strong* erroneous behavior appears with newer versions of Maven it is clear :) > Dependency with 'provided' scope has its transitive dependency included in > final artifact > - > > Key: MNG-5255 > URL: https://jira.codehaus.org/browse/MNG-5255 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.0.4 > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: D:\bin\apache-maven-3.0.4 > Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: D:\bin\java\jdk1.6.0_27\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Bart Skondin > Attachments: provided-scope-not-working.zip > > > Expected: A dependency declared with a scope of 'provided', along with any > transitive dependencies, should not be included in the final artifact. > Actual: I have a dependency, jsp-api, declared with 'provided' scope. This > dependency has a dependency of its own, servlet-api. The servlet-api.jar is > being included in the web-inf/lib folder of the resultant war file. > Background: We recently upgraded from Maven 2.2.1 to Maven 3.0.4. The problem > was not witnessed until after the upgrade. > Steps to Reproduce: Run mvn install, then have a look at the web-inf/lib > folder. Notice that the servlet-api.jar has been included. > Additional Info: It seems that I can only reproduce this behavior when > declaring a specific dependency in my pom, spring-ldap. Here is the > dependency tree for the given pared-down project (attached): > --- maven-dependency-plugin:2.1:tree (default-cli) @ > provided-scope-not-working --- > com.bug.example:provided-scope-not-working:war:0.0.1-SNAPSHOT > +- javax.servlet:jsp-api:jar:2.0:provided > | \- javax.servlet:servlet-api:jar:2.4:provided > \- org.springframework.ldap:spring-ldap:jar:1.2.1:compile >+- commons-logging:commons-logging:jar:1.0.4:compile >+- commons-lang:commons-lang:jar:2.1:compile >+- org.springframework:spring-beans:jar:2.0.6:compile >| +- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) >| \- (org.springframework:spring-core:jar:2.0.6:compile - omitted for > duplicate) >\- org.springframework:spring-core:jar:2.0.6:compile > \- (commons-logging:commons-logging:jar:1.1:compile - omitted for > conflict with 1.0.4) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-35) Website typo in footer
[ https://jira.codehaus.org/browse/MSKINS-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSKINS-35. - Resolution: Fixed I've redeployed the site using the latest siteskinner-maven-plugin. Wait for the sync until the footer is correct. > Website typo in footer > -- > > Key: MSKINS-35 > URL: https://jira.codehaus.org/browse/MSKINS-35 > Project: Maven Skins > Issue Type: Bug > Components: Fluido Skin > Environment: http://maven.apache.org/skins/maven-fluido-skin/ >Reporter: SebbASF >Assignee: Simone Tripodi > Fix For: fluido-1.2.2 > > > The website footer says: > bq. Apache Maven, Apache Apache Maven Fluido Skin, Apache, the Apache feather > logo ... > There's a duplicated Apache. > Also, the page title says just "Introduction" which isn't very informative. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-49) Odd looking footers in layout pages
[ https://jira.codehaus.org/browse/MSKINS-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302123#comment-302123 ] Dennis Lundberg commented on MSKINS-49: --- Those footers were added to the ITs in r1198501 by Simone. Commit message was: "better footer rendering, ITs shows Apache addresses" > Odd looking footers in layout pages > --- > > Key: MSKINS-49 > URL: https://jira.codehaus.org/browse/MSKINS-49 > Project: Maven Skins > Issue Type: Bug > Environment: > http://maven.apache.org/skins/maven-fluido-skin/sidebar/index.html > http://maven.apache.org/skins/maven-fluido-skin/topbar/index.html >Reporter: SebbASF > > The page footer contains two address blocks that don't really belong there. > See below > Copyright © 2002-2012 The Apache Software Foundation. All Rights Reserved. > Apache Maven, Apache @project.name@, Apache, the Apache feather logo, and the > Apache Maven project logos are trademarks of The Apache Software Foundation. > All other marks mentioned may be trademarks or registered trademarks of their > respective owners. > The Apache Software Foundation > Dept. 9660 > Los Angeles, CA 90084-9660 > USA > Fax: +1.919.573.9199 > The Apache Software Foundation > 1901 Munsey Drive > Forest Hill, MD 21050-2747 > USA > apache at apache dot org -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-50) Breadcrumb links do not all work on layout sample pages
[ https://jira.codehaus.org/browse/MSKINS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302126#comment-302126 ] Dennis Lundberg commented on MSKINS-50: --- Yes, the breadcrumbs in the site.xml files of the ITs are wrong. They use absolute links, which won't work there. > Breadcrumb links do not all work on layout sample pages > --- > > Key: MSKINS-50 > URL: https://jira.codehaus.org/browse/MSKINS-50 > Project: Maven Skins > Issue Type: Bug > Environment: > http://maven.apache.org/skins/maven-fluido-skin/topbar/index.html > http://maven.apache.org/skins/maven-fluido-skin/sidebar/index.html >Reporter: SebbASF > > The breadcrumb navigation contains: > Apache / Maven / skins / maven-fluido-skin / Apache Maven Fluido Skin IT, > sidebar layout > However, only the 1st two links (i.e. Apache / Maven ) actually work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-27) Sample site is broken for maven-stylus-skin
[ https://jira.codehaus.org/browse/MSKINS-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSKINS-27. - Resolution: Fixed Assignee: Dennis Lundberg I've redeployed the site, generating it using 'mvn clean verify site -Prun-its,reporting'. > Sample site is broken for maven-stylus-skin > --- > > Key: MSKINS-27 > URL: https://jira.codehaus.org/browse/MSKINS-27 > Project: Maven Skins > Issue Type: Bug > Components: Stylus Skin >Affects Versions: stylus-1.4 >Reporter: Joe Littlejohn >Assignee: Dennis Lundberg >Priority: Minor > > The sample site link on this page: > http://maven.apache.org/skins/maven-stylus-skin/ > links to: > http://maven.apache.org/skins/maven-stylus-skin/sample/ > however this link gives a 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-48) make Fluido Skin more responsive
[ https://jira.codehaus.org/browse/MSKINS-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302130#comment-302130 ] Dennis Lundberg commented on MSKINS-48: --- Do you know if this got incorporated into bootstrap 2.0.4? See MSKINS-54. > make Fluido Skin more responsive > > > Key: MSKINS-48 > URL: https://jira.codehaus.org/browse/MSKINS-48 > Project: Maven Skins > Issue Type: Improvement > Components: Fluido Skin >Affects Versions: fluido-1.2.1 >Reporter: Hugues Obolonsky > Attachments: fluido-responsive.patch > > > The maven fluido skin is not optimise for cellphone device. > Patch provided as a proposition but maybe need more css tuning. > The patch provide an upgraded version of bootstrap with .hidden_phone > class which work on tag. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-728) The commit message for release:branch is wrong
[
https://jira.codehaus.org/browse/MRELEASE-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302156#comment-302156
]
Joseph Walton commented on MRELEASE-728:
You're right, the current behaviour doesn't match the original report exactly,
but I think it's correct.
By default, there is no commit in the new branch - it keeps the same version as
the original branch. The commit message in the original branch is:
{noformat}
[maven-release-plugin] prepare for next development iteration
{noformat}
Which is what you want in a branch-for-release workflow. If you use
{{updateBranchVersions}} then you end up with:
||commit||branch||commit message||
|3|master|[maven-release-plugin] prepare for next development iteration|
|2|new-branch|[maven-release-plugin] prepare branch new-branch|
|1| |[maven-release-plugin] prepare for next development iteration|
The unnecessary commit in master is due to MRELEASE-729, but I think the
messages are fine.
> The commit message for release:branch is wrong
> --
>
> Key: MRELEASE-728
> URL: https://jira.codehaus.org/browse/MRELEASE-728
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: branch, Git
>Affects Versions: 2.2.1
> Environment: git 1.7.5.4
>Reporter: Adrien Ragot
>Assignee: Robert Scholte
> Fix For: 2.3
>
>
> Using Git, when you do mvn release:branch -DbranchName=xxx,
> the commit message for master is "[maven-release-plugin] prepare release xxx".
> The right commit message should be "[maven-release-plugin] prepare branch
> xxx", like for Svn.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5306) for IDE embedding have ways of collecting model problems without failing the process
Milos Kleint created MNG-5306: - Summary: for IDE embedding have ways of collecting model problems without failing the process Key: MNG-5306 URL: https://jira.codehaus.org/browse/MNG-5306 Project: Maven 2 & 3 Issue Type: New Feature Components: Embedding, IDEs, POM Affects Versions: 3.0.4 Reporter: Milos Kleint Priority: Critical Currently the IDE integrations need to perform 2 steps: 1. load the POM with no validation in place. Having a MavenProject instance in the most cases possible is important. 2. to display the warnings in pom editor and elsewhere one has to run at least the projectbuilder/modelbuilder with proper validation level and collect the results from either the result object or the exception thrown. The proposed patch in https://github.com/mkleint/maven-3/commits/trunk makes it possible to have both a MAvenproject instance under minimal validation constraints and collect the validation problems for any higher validation levels. Additional benefit of the patch is that it logs "since what version of Maven is the problem valid". Which can be further used in both cmd line and IDE error reporting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5306) for IDE embedding have ways of collecting model problems without failing the process
[ https://jira.codehaus.org/browse/MNG-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=302166#comment-302166 ] Milos Kleint commented on MNG-5306: --- https://github.com/mkleint/maven-3/commit/0540107c332c7795226e95fb46bff722388ffae4 adds a Version field to ModelProblem which denotes since what validation level/maven version, the problem applies. https://github.com/mkleint/maven-3/commit/098f02010d4b5d19b90006e25087e992b73a5ded moves the decision making about failing the model building from the collector object to default model builder, in overridable protected method. The IDE integration can replace the default implementation with a subclass that performs a full 31 validation but fails the building only when base problems are found. > for IDE embedding have ways of collecting model problems without failing the > process > > > Key: MNG-5306 > URL: https://jira.codehaus.org/browse/MNG-5306 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: Embedding, IDEs, POM >Affects Versions: 3.0.4 >Reporter: Milos Kleint >Priority: Critical > > Currently the IDE integrations need to perform 2 steps: > 1. load the POM with no validation in place. Having a MavenProject instance > in the most cases possible is important. > 2. to display the warnings in pom editor and elsewhere one has to run at > least the projectbuilder/modelbuilder with proper validation level and > collect the results from either the result object or the exception thrown. > The proposed patch in https://github.com/mkleint/maven-3/commits/trunk makes > it possible to have both a MAvenproject instance under minimal validation > constraints and collect the validation problems for any higher validation > levels. > Additional benefit of the patch is that it logs "since what version of Maven > is the problem valid". Which can be further used in both cmd line and IDE > error reporting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
