[jira] (MEJB-60) Optional classifer for ejb-client
Will Tatam created MEJB-60: -- Summary: Optional classifer for ejb-client Key: MEJB-60 URL: https://jira.codehaus.org/browse/MEJB-60 Project: Maven 2.x EJB Plugin Issue Type: New Feature Affects Versions: 2.3 Reporter: Will Tatam Attachments: generateClassifiedClient.patch It is sometimes necessary to have an EJB jar which requires a classifier, but that does not automatically mean that you want your ejb-client to always have a classifier too and infact the current code has a comment next to the creation of the client stating TODO: shouldn't need classifier Patch attached created new config option called generateClassifiedClient which is true by default, to maintain previous behavour, but can be set to true in the configuration section of the pom to false should you wish to have a non-classified client -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-967) ArrayIndexOutOfBounds in SmartStackTraceParser
[
https://jira.codehaus.org/browse/SUREFIRE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-967.
---
Resolution: Fixed
Assignee: Kristian Rosenvold
Fixed in c513cbc5b76619a6164e2ef3a79511d81dea878b, try 2.15-SNAPSHOT
ArrayIndexOutOfBounds in SmartStackTraceParser
--
Key: SUREFIRE-967
URL: https://jira.codehaus.org/browse/SUREFIRE-967
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.13
Environment: *
Reporter: Rastislav Cesnek
Assignee: Kristian Rosenvold
We are testing using JUnit tests against Webshphere 7 aplication server.
For some whatever strange reason, WebSphere creates an exception chain, in
which not all exceptions in the chain have a stack trace array filled in. (I
have heard rumors of JVMs loosing stack traces in exceptions under some
strange conditions).
The result is the following exception in Surefire 2.13 (with 2.11, the tests
pass and report is generated correctly as the exception processing is
different from 2.13 as I have seen):
{code}
[INFO] There was an error in the forked process
org.apache.maven.surefire.testset.TestSetFailedException:
java.lang.ArrayIndexOutOfBoundsException: 0; nested exception is
java.lang.ArrayIndexOutOfBoundsException: 0
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176)
at
org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131)
at
org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:73)
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.testError(ForkingRunListener.java:131)
at
org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:111)
at
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:267)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.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)
{code}
The exception chain received by JUnit test case from WebShpere basically is
as follows (two outermost exceptions have empty stack trace array):
{code}
SEVERE: Exception 1
Excpetion
[jira] (SUREFIRE-967) ArrayIndexOutOfBounds in SmartStackTraceParser
[
https://jira.codehaus.org/browse/SUREFIRE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-967:
Fix Version/s: 2.15
ArrayIndexOutOfBounds in SmartStackTraceParser
--
Key: SUREFIRE-967
URL: https://jira.codehaus.org/browse/SUREFIRE-967
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.13
Environment: *
Reporter: Rastislav Cesnek
Assignee: Kristian Rosenvold
Fix For: 2.15
We are testing using JUnit tests against Webshphere 7 aplication server.
For some whatever strange reason, WebSphere creates an exception chain, in
which not all exceptions in the chain have a stack trace array filled in. (I
have heard rumors of JVMs loosing stack traces in exceptions under some
strange conditions).
The result is the following exception in Surefire 2.13 (with 2.11, the tests
pass and report is generated correctly as the exception processing is
different from 2.13 as I have seen):
{code}
[INFO] There was an error in the forked process
org.apache.maven.surefire.testset.TestSetFailedException:
java.lang.ArrayIndexOutOfBoundsException: 0; nested exception is
java.lang.ArrayIndexOutOfBoundsException: 0
java.lang.ArrayIndexOutOfBoundsException: 0
at
org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176)
at
org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131)
at
org.apache.maven.surefire.common.junit4.JUnit4StackTraceWriter.smartTrimmedStackTrace(JUnit4StackTraceWriter.java:73)
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.testError(ForkingRunListener.java:131)
at
org.apache.maven.surefire.common.junit4.JUnit4RunListener.testFailure(JUnit4RunListener.java:111)
at
org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100)
at
org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41)
at
org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97)
at
org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:267)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:69)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:48)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:292)
at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.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)
{code}
The exception chain received by JUnit test case from WebShpere basically is
as follows (two outermost exceptions have empty stack trace array):
{code}
SEVERE: Exception 1
Excpetion class: javax.ejb.EJBTransactionRolledbackException
Exception message: nested exception
[jira] (SUREFIRE-960) Read from excel to run test-cases
[ https://jira.codehaus.org/browse/SUREFIRE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-960. --- Resolution: Won't Fix Read from excel to run test-cases - Key: SUREFIRE-960 URL: https://jira.codehaus.org/browse/SUREFIRE-960 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 2.13 Reporter: arun reddy Assignee: Kristian Rosenvold Read from excel from which we read two columns one column has Testclass names and second column(column2) has true and false values. I want to run the test classes whose respective column2 value is true and exclude the test classes whose respective column2 value is false. I tried creating a maven plugin to read the excel and fetch the test-class names but I dont know how to run those testclasses only. It would be great and helpful to my project if any one provide a solution for this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-960) Read from excel to run test-cases
[ https://jira.codehaus.org/browse/SUREFIRE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-960. --- Resolution: Duplicate Assignee: Kristian Rosenvold The file based feature should be enough for excel users too; we won't be adding excel specific features Read from excel to run test-cases - Key: SUREFIRE-960 URL: https://jira.codehaus.org/browse/SUREFIRE-960 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 2.13 Reporter: arun reddy Assignee: Kristian Rosenvold Read from excel from which we read two columns one column has Testclass names and second column(column2) has true and false values. I want to run the test classes whose respective column2 value is true and exclude the test classes whose respective column2 value is false. I tried creating a maven plugin to read the excel and fetch the test-class names but I dont know how to run those testclasses only. It would be great and helpful to my project if any one provide a solution for this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-960) Read from excel to run test-cases
[ https://jira.codehaus.org/browse/SUREFIRE-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold reopened SUREFIRE-960: - Read from excel to run test-cases - Key: SUREFIRE-960 URL: https://jira.codehaus.org/browse/SUREFIRE-960 Project: Maven Surefire Issue Type: New Feature Components: Maven Surefire Plugin Affects Versions: 2.13 Reporter: arun reddy Assignee: Kristian Rosenvold Read from excel from which we read two columns one column has Testclass names and second column(column2) has true and false values. I want to run the test classes whose respective column2 value is true and exclude the test classes whose respective column2 value is false. I tried creating a maven plugin to read the excel and fetch the test-class names but I dont know how to run those testclasses only. It would be great and helpful to my project if any one provide a solution for this -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-965) Changed behaviour for Maven properties from surefire 2.12.4 to 2.13
[ https://jira.codehaus.org/browse/SUREFIRE-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321537#comment-321537 ] Kristian Rosenvold commented on SUREFIRE-965: - This issue will be closed in a few days unless some reproducible testcase or other information shows up Changed behaviour for Maven properties from surefire 2.12.4 to 2.13 --- Key: SUREFIRE-965 URL: https://jira.codehaus.org/browse/SUREFIRE-965 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.13 Environment: Maven 3.0.4 JDK 1.7.0_10 Windows Reporter: Odin Hole Standal Priority: Minor We just upgraded Surefire from 2.12.4 to 2.13 and witnessed a change in behaviour with respect to system properties defined in Maven profiles. Our build is a multi-module one with a nested structure. In our parent project, we define profiles that set a system property to either 'A' or 'B'. Our tests rely on this system property being set to either 'A' or 'B' across all tests in all modules. However, when we upgraded to 2.13 and ran tests with profile 'A', suddenly one of the modules in the build changed the property from 'A' to 'B'. Is there any changes between 2.12.4 and 2.13 that might explain this behaviour? I could not find any suspects in either the code or the change list. I'm sorry, but I can't share the build configuration. Sincerely -- Odin Hole Standal -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-959) ArrayIndexOutOfBoundsException is thrown occasionally at the end of TestNG test
[ https://jira.codehaus.org/browse/SUREFIRE-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-959. --- Resolution: Duplicate Assignee: Kristian Rosenvold The duplicate SUREFIRE-967 has been fixed ArrayIndexOutOfBoundsException is thrown occasionally at the end of TestNG test Key: SUREFIRE-959 URL: https://jira.codehaus.org/browse/SUREFIRE-959 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.13 Reporter: Kobi Kisos Assignee: Kristian Rosenvold java.lang.ArrayIndexOutOfBoundsException: 0 at org.apache.maven.surefire.report.SmartStackTraceParser.rootIsInclass(SmartStackTraceParser.java:176) at org.apache.maven.surefire.report.SmartStackTraceParser.getString(SmartStackTraceParser.java:131) at org.apache.maven.surefire.report.PojoStackTraceWriter.smartTrimmedStackTrace(PojoStackTraceWriter.java:61) 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:334) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:329) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:291) at org.testng.SuiteRunner.run(SuiteRunner.java:240) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1198) at org.testng.TestNG.runSuitesLocally(TestNG.java:1123) at org.testng.TestNG.run(TestNG.java:1031) at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:77) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:189) at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:105) 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:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-954) Hard-to-believe abstract method error
[
https://jira.codehaus.org/browse/SUREFIRE-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-954.
---
Resolution: Cannot Reproduce
Assignee: Kristian Rosenvold
From our discussions it would seem like this problem was caused by an
exception that was instantiated in native code with an incorrect classloader.
I would really appreciate a testcase for this, and will happily re-open this
issue if such a testcase emerges
Hard-to-believe abstract method error
-
Key: SUREFIRE-954
URL: https://jira.codehaus.org/browse/SUREFIRE-954
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.13
Reporter: Benson Margulies
Assignee: Kristian Rosenvold
I have a set of junit test that I am running with Surefire 2.13 with forkMode
always. Two classes die with the following hard-to-belive backtrace. The
others are fine. Sadly, I can't open-source the test case, so I'm hoping that
you will give me some advice as to how to be a remote-control debugging
assistant to look into this. The AbstractMethodError is very hard for me to
imagine explaining.
{noformat}
Running com.basistech.TestLogCallback
0[main] DEBUG com.basistech.rlp.RLPEnvironment - Starting cleanup thread
6[main] DEBUG com.basistech.rlp.RLPEnvironment - cleanupContext
java.lang.ref.PhantomReference@509df6f1 7f9e59a073b0
6[RLP Context Cleanup] DEBUG com.basistech.rlp.RLPEnvironment -
Exiting cleanup thread
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
java.lang.AbstractMethodError:
java.lang.Throwable.printStackTrace(Ljava/io/PrintWriter;)V
at
org.apache.maven.surefire.report.LegacyPojoStackTraceWriter.writeTraceToString(LegacyPojoStackTraceWriter.java:54)
at
org.apache.maven.surefire.booter.ForkingRunListener.encode(ForkingRunListener.java:330)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:104)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-950) ClassNotFoundException org.apache.xerces.parsers.SAXParser not found
[ https://jira.codehaus.org/browse/SUREFIRE-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-950. --- Resolution: Fixed This issue was fixed in m-s-u 0.3, part of surefire 2.14 ClassNotFoundException org.apache.xerces.parsers.SAXParser not found Key: SUREFIRE-950 URL: https://jira.codehaus.org/browse/SUREFIRE-950 Project: Maven Surefire Issue Type: Bug Components: Maven Failsafe Plugin Affects Versions: 2.13 Reporter: Zlika Assignee: Kristian Rosenvold Fix For: 2.14 Attachments: failsafe.txt When I build my project on our Jenkins server, I have a java.lang.ClassNotFoundException: org.apache.xerces.parsers.SAXParser at the end of the build due to failsafe plugin (cf. attached log) during the verify phase. The problem does not appear on my local computer (running windows), only on the Jenkins server (running Linux). The problem also only appears when I use the maven site phase (mvn clean install site), it does not appear, even on Jenkins, when I do a simple mvn clean install. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-965) Changed behaviour for Maven properties from surefire 2.12.4 to 2.13
[ https://jira.codehaus.org/browse/SUREFIRE-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321541#comment-321541 ] Odin Hole Standal commented on SUREFIRE-965: Sorry, I haven't been able to reproduce this issue in a smaller project. Changed behaviour for Maven properties from surefire 2.12.4 to 2.13 --- Key: SUREFIRE-965 URL: https://jira.codehaus.org/browse/SUREFIRE-965 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.13 Environment: Maven 3.0.4 JDK 1.7.0_10 Windows Reporter: Odin Hole Standal Priority: Minor We just upgraded Surefire from 2.12.4 to 2.13 and witnessed a change in behaviour with respect to system properties defined in Maven profiles. Our build is a multi-module one with a nested structure. In our parent project, we define profiles that set a system property to either 'A' or 'B'. Our tests rely on this system property being set to either 'A' or 'B' across all tests in all modules. However, when we upgraded to 2.13 and ran tests with profile 'A', suddenly one of the modules in the build changed the property from 'A' to 'B'. Is there any changes between 2.12.4 and 2.13 that might explain this behaviour? I could not find any suspects in either the code or the change list. I'm sorry, but I can't share the build configuration. Sincerely -- Odin Hole Standal -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-801) Wrong value of tag element from branch
[ https://jira.codehaus.org/browse/MRELEASE-801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321542#comment-321542 ] Dan Rollo commented on MRELEASE-801: I found the way the release-plugin adds the tagHEAD/tag when no prior tag element existed surprising. The behavior described for the patch seems more logical (and is less surprising). Wrong value of tag element from branch Key: MRELEASE-801 URL: https://jira.codehaus.org/browse/MRELEASE-801 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch, Git Affects Versions: 2.3.2 Reporter: Benson Margulies Attachments: 0001-MRELEASE-801-don-t-use-scm.tag-HEAD-for-GIT-provider.patch The branch mojo produces tagHEAD/tag. This can't be right; HEAD isn't the name of a branch, it's the name of a ref. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-274) Conditionally include or exclude a file from archetype during generation
[ https://jira.codehaus.org/browse/ARCHETYPE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321549#comment-321549 ] Antonel Pazargic commented on ARCHETYPE-274: Any updates on this? Conditionally include or exclude a file from archetype during generation Key: ARCHETYPE-274 URL: https://jira.codehaus.org/browse/ARCHETYPE-274 Project: Maven Archetype Issue Type: Improvement Components: Generator Affects Versions: 2.0-alpha-4 Reporter: Dan Allen I would like to be able to control which files are placed into the generated project based on the value of a property that is defined during archetype:generate. For instance, I forsee the following prompt: Define value for groupId: : com.example Define value for artifactId: : myproject Define value for package: com.example: : Define value for extraSupport: : y Based on the value of extraSupport, I want to include (or not include) a file in the generated project. If the user does not want the extra support, I don't want to clutter up the generated project with unnecessary files. It's all about customization of the project based on what the developer intends to use. While I could create a whole other archetype, sometimes the changes are so slight that it would be easier to include/exclude a file. Is there a way to control this behavior using the archetype-metadata.xml descriptor? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (ARCHETYPE-424) Conditionally include or exclude a fileSet from an archetype when project is generated
[
https://jira.codehaus.org/browse/ARCHETYPE-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321548#comment-321548
]
Antonel Pazargic commented on ARCHETYPE-424:
I am working on a multi module projects, and each new module might have a
couple of supports (JPA, REST, Cache) based on developer input (through
archetype custom properties).
Based on chosen supports some files have to be generated.
So far I don't find a way to address this.
Is there a hope to have such a support in maven archetype generator?
Thank you.
Conditionally include or exclude a fileSet from an archetype when project is
generated
--
Key: ARCHETYPE-424
URL: https://jira.codehaus.org/browse/ARCHETYPE-424
Project: Maven Archetype
Issue Type: New Feature
Reporter: Adrian
I'm creating a project generating code samples for accessing Oracle and
Mainframe.
I want to conditionnaly generate the samples based on user input
Define value for groupId: : com.example
Define value for artifactId: : myproject
Define value for package: com.example: :
Define value for SGBD Sample : : Y
Define value for Mainframe Sample : : N
Could it be possible to add this functionnality ?
i.e. This could be done by adding an attribute into fileSet element which
would indicate if the fileSet directive needs to be taken into account :
{code:xml}
fileSet filtered=true encoding=UTF-8 enable=${mainframeSample}
directorysrc/main/java/directory
includes
includemainframe/*.java/include
/includes
/fileSet
{code}
Some links :
*
[http://stackoverflow.com/questions/1919704/how-do-i-conditionally-include-or-exclude-a-file-from-an-archetype-when-project]
* [ARCHETYPE-58|http://jira.codehaus.org/browse/ARCHETYPE-58] (this one
didn't adressed this issue)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-391) Unpack fails on linux with large archives
[ https://jira.codehaus.org/browse/MDEP-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321555#comment-321555 ] Brian Fox commented on MDEP-391: changed the default permission back to false for backwards compat Unpack fails on linux with large archives - Key: MDEP-391 URL: https://jira.codehaus.org/browse/MDEP-391 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: unpack Affects Versions: 2.6 Environment: Ubuntu 10.04 LTS Reporter: Benoit Montuelle Attachments: lsof.txt When unpacking large archives with numerous files (more than 1024 on this os) I got the following error trace [INFO] Expanding /var/lib/deploy/.m2/repository/com/aprilwaf/wafservice/ihm-packaging-ecg/3.9-finsouscription-SNAPSHOT/ihm-packaging-ecg-3.9-finsouscription-SNAPSHOT-distribution-php.tar.gz to /tmp/tmp5620480517649479513.tar [INFO] Expanding: /tmp/tmp5620480517649479513.tar into /var/lib/deploy/build-deploy/ecg/target/classes org.codehaus.plexus.archiver.ArchiverException: Error while executing chmod. at org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:64) at org.codehaus.plexus.archiver.zip.AbstractZipUnArchiver.extractFile(AbstractZipUnArchiver.java:236) at org.codehaus.plexus.archiver.tar.TarUnArchiver.execute(TarUnArchiver.java:92) at org.codehaus.plexus.archiver.tar.TarGZipUnArchiver.execute(TarGZipUnArchiver.java:76) at org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:108) at org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:260) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.unpackArtifact(UnpackMojo.java:122) at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:95) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:652) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:102) at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89) at org.codehaus.plexus.archiver.util.ArchiveEntryUtils.chmod(ArchiveEntryUtils.java:45) ... 26 more Caused by: java.io.IOException: Cannot run program /bin/sh (in directory /var/lib/deploy/build-deploy/ecg/target/classes/symfony-1.4/lib/plugins/sfDoctrinePlugin/test/unit/record): java.io.IOException: error=24, Too many open files at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at java.lang.Runtime.exec(Runtime.java:593) at org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:647) ... 29 more Caused by: java.io.IOException: java.io.IOException: error=24, Too many open files at java.lang.UNIXProcess.init(UNIXProcess.java:148) at java.lang.ProcessImpl.start(ProcessImpl.java:65) at
[jira] (MPIR-269) (optionally) create dependency convergence also for single module projects
[ https://jira.codehaus.org/browse/MPIR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321557#comment-321557 ] Steven Swor commented on MPIR-269: -- Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. If the behavior isn't going to be changed, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? (optionally) create dependency convergence also for single module projects -- Key: MPIR-269 URL: https://jira.codehaus.org/browse/MPIR-269 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependency-convergence Affects Versions: 2.6 Reporter: Michael Wenig We are using the dependency convergence report for a quick check if a project could be released or not. Unfortunately the report is not created for single module projects. MPIR-10 mentions that it is useful for multi module and therefore disabled by default for single module projects. Unfortunately by default is not correct as there is no option to activate it. At our site the report also makes sense for single modules. The report shows if there are snapshot versions of other projects used. Of course someone could take a look into the dependency report and search for SNAPSHOT. But it is a lot easier for the developers to follow a simple rule look into this report - and it could be used programmatically if the report is alway present. Is there any reason against activating this report also for single module (an option which is false per default would be sufficient)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-269) (optionally) create dependency convergence also for single module projects
[ https://jira.codehaus.org/browse/MPIR-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=321557#comment-321557 ] Steven Swor edited comment on MPIR-269 at 3/6/13 4:29 PM: -- Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. At the very least, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? was (Author: sworisbreathing): Agreed. The ready for release info in this report is useful for single-module projects. I just spent a good half hour trying to figure out why the report wouldn't run for my project, and ended up stepping through the code in a debugger until I found it. If the behavior isn't going to be changed, can someone please at least update the documentation for this goal to mention that it requires a reactor build (or only generates a report for multi-module projects)? (optionally) create dependency convergence also for single module projects -- Key: MPIR-269 URL: https://jira.codehaus.org/browse/MPIR-269 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Components: dependency-convergence Affects Versions: 2.6 Reporter: Michael Wenig We are using the dependency convergence report for a quick check if a project could be released or not. Unfortunately the report is not created for single module projects. MPIR-10 mentions that it is useful for multi module and therefore disabled by default for single module projects. Unfortunately by default is not correct as there is no option to activate it. At our site the report also makes sense for single modules. The report shows if there are snapshot versions of other projects used. Of course someone could take a look into the dependency report and search for SNAPSHOT. But it is a lot easier for the developers to follow a simple rule look into this report - and it could be used programmatically if the report is alway present. Is there any reason against activating this report also for single module (an option which is false per default would be sufficient)? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
