[jira] (SUREFIRE-827) Surefire 2.12 cannot run a single test, regression from 2.11
[ https://jira.codehaus.org/browse/SUREFIRE-827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291701#comment-291701 ] François LEIBER commented on SUREFIRE-827: -- You're right, I read the ticket title a bit quickly, I'm creating another one (and yes, it happens all the time). > Surefire 2.12 cannot run a single test, regression from 2.11 > > > Key: SUREFIRE-827 > URL: https://jira.codehaus.org/browse/SUREFIRE-827 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.12 > Environment: Ubuntu 11.10 >Reporter: Andrew Gaul >Assignee: Kristian Rosenvold > > # Surefire 2.11 > $ mvn test -Dtest=DataTest#testDataServerGetNonExistentFile > ... > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > # Surefire 2.12 > mvn test -Dtest=DataTest#testDataServerGetNonExistentFile > ... > Tests run: 9, Failures: 0, Errors: 0, Skipped: 0 -- 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-837) Surefire 2.12 fails after first module
François LEIBER created SUREFIRE-837:
Summary: Surefire 2.12 fails after first module
Key: SUREFIRE-837
URL: https://jira.codehaus.org/browse/SUREFIRE-837
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.12
Environment: Maven 3.0.4, surefire 2.12, JUnit 4.10, JDK1.6_30, WinXP
Reporter: François LEIBER
Attachments: surefire2.12.log
We have a big issue with surefire 2.12 (using default configuration, which
means forkMode=once): the Junit tests of the first module pass perfectly, then
we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
{code}
The forked VM terminated without saying properly goodbye. VM crash or
System.exit called ?
at
org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
{code}
It seems related to the following code, taken from
maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java:
{code}
runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
providerConfiguration );
// Say bye.
System.out.println("Z,0,BYE!");
System.out.flush();
// noinspection CallToSystemExit
System.exit( 0 );
{code}
This happens at every run, just reverting surefire to 2.11 fixes the issue. If
I use forkMode=never, it works, but our code needs a forked VM, otherwise we
have SecurityManager issues.
The surefire configuration itself is very basic:
{code}
org.apache.maven.plugins
maven-surefire-plugin
2.12
-Xms128m -Xmx1024m
**/SelfHostingTests.java
{code}
Attached is the full build log with -X.
--
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-838) Specifying groups configuration option does not automatically make surefire select the junit47 provider
Martin Burger created SUREFIRE-838: -- Summary: Specifying groups configuration option does not automatically make surefire select the junit47 provider Key: SUREFIRE-838 URL: https://jira.codehaus.org/browse/SUREFIRE-838 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12 Reporter: Martin Burger I am trying to use JUnit categories to execute a selected set of unit tests. For that purpose, I added the groups configuration option. However, when I execute mvn test, all tests are executed. Only after I manually specified surefire-junit47 as provider, Surefire takes groups into account. Thus, it seems that Surefire does not select the junit47 provider automatically. -- 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-839) If no tests are found that would match a given JUnit category, mvn test should not fail in multi-module project
Martin Burger created SUREFIRE-839: -- Summary: If no tests are found that would match a given JUnit category, mvn test should not fail in multi-module project Key: SUREFIRE-839 URL: https://jira.codehaus.org/browse/SUREFIRE-839 Project: Maven Surefire Issue Type: Bug Components: Junit 4.7+ (parallel) support Affects Versions: 2.12 Reporter: Martin Burger In a multi-module project, I configured Surefire to execute tests of a selected JUnit category only. Unfortunately, not all modules contain tests in that category, which makes mvn test fail: Tests in error: initializationError(org.junit.runner.manipulation.Filter): No tests found matching *foo.junit.categories.SlowTests from org.junit.runner.Request$1@15a If a module does not contain any test that would match the given category, Surefire should continue instead. Note that specifying -DfailIfNoTests=false does not help in that case. -- 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-835) Tests for maven plugins are incompatible with maven 3.0.4
[
https://jira.codehaus.org/browse/SUREFIRE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291733#comment-291733
]
Ruslan Diachenko commented on SUREFIRE-835:
---
Thank you! I've changed my version of surefire to 2.12 and it resolved the
problem.
> Tests for maven plugins are incompatible with maven 3.0.4
> -
>
> Key: SUREFIRE-835
> URL: https://jira.codehaus.org/browse/SUREFIRE-835
> Project: Maven Surefire
> Issue Type: Bug
>Reporter: Ruslan Diachenko
>Assignee: Kristian Rosenvold
> Attachments: simple-test.zip
>
>
> Steps will reproduce the problem:
> 1. Write test for maven plugin by extending test class from
> AbstractMojoTestCase (package org.apache.maven.plugin.testing)
> public class SimpleMavenTest extends AbstractMojoTestCase {
> @Override
> protected void setUp() throws Exception {
> super.setUp();
> // code
> }
> public void test() throws Exception {
> // test case
> }
> @Override
> protected void tearDown() throws Exception {
> // code
> super.tearDown();
> }
> }
> 2. Configure maven-surefire-plugin as follows:
>
>
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> never
>
>
>
>
> 3. Run "mvn test" on maven 3.0.4
> Detected:
> java.lang.IllegalStateException: The internal default plexus-bootstrap.xml is
> missing. This is highly irregular, your plexus JAR is most likely corrupt.
> at
> org.codehaus.plexus.DefaultPlexusContainer.initializeConfiguration(DefaultPlexusContainer.java:1052)
> at
> org.codehaus.plexus.DefaultPlexusContainer.initialize(DefaultPlexusContainer.java:627)
> at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:119)
> at
> org.apache.maven.plugin.testing.AbstractMojoTestCase.setUp(AbstractMojoTestCase.java:69)
> at org.maven.test.MyMojoTest.setUp(MyMojoTest.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:128)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:120)
> at junit.framework.TestSuite.runTest(TestSuite.java:230)
> at junit.framework.TestSuite.run(TestSuite.java:225)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Error occurred only when never. If we change forkMode
> value to "once" or another one, test will run succesfully. On maven 3.0.3 and
> previous maven versions the test was run without any errors.
--
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] (MJAR-151) Error assembling JAR on OS X
Jason Tovey created MJAR-151: Summary: Error assembling JAR on OS X Key: MJAR-151 URL: https://jira.codehaus.org/browse/MJAR-151 Project: Maven 2.x JAR Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Mac OS X 10.6.8 Reporter: Jason Tovey Priority: Blocker Attachments: maven-jar-osx-debug-output.txt PlexusIoResourceAttributeUtils tries to execute '/bin/sh -c ls -1lad /Developer/codebase/ABC/pom.xml' and does not get the output it was expecting. Running that command from the shell only lists the contents of the current directory as a plain 'ls' would. Enclosing the whole 'ls' command inside quotes as it's passed to '/bin/sh -c' seems to fix the problem. I.e., '/bin/sh -c "ls -1lad /Developer/codebase/ABC/pom.xml"'. Sorry in advance if this isn't a 'Maven 2.x JAR Plugin' issue or if it's not a blocker; but I don't know a workaround other than not using Maven. -- 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-836) regression with surefire 2.12 plugin and SecurityManager
[ https://jira.codehaus.org/browse/SUREFIRE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291755#comment-291755 ] Kristian Rosenvold commented on SUREFIRE-836: - The test project seems to require a database ? > regression with surefire 2.12 plugin and SecurityManager > > > Key: SUREFIRE-836 > URL: https://jira.codehaus.org/browse/SUREFIRE-836 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12 > Environment: mvn --version > Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: /home/henning/.mvn > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.30/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.34.9-69.fc13.x86_64", arch: "amd64", family: > "unix" > (also with maven 3.0.3) >Reporter: Henning Schmiedehausen > > We are running all our tests using a special security manager that restricts > IO in tests. There is a regression when running these tests with the 2.12 > plugin compared to the 2.11 plugin: > How to reproduce: > 1) git clone g...@github.com:NessComputing/components-ness-pg.git > 2) mvn clean compile test-compile > 3) Run the tests with the 2.11 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.11:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.11:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > 2012-02-14 15:15:06,823 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:77): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > 4) Run the tests with the 2.12 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.12:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.12:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec > Z,0,BYE! > 2012-02-14 15:15:32,233 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:79): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.334s > [INFO] Finished at: Tue Feb 14 15:15:32 PST 2012 > [INFO] Final Memory: 5M/181M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-cli) on > project ness-pg: Execution default-cli of goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test failed: The forked > VM terminated without saying properly goodbye. VM crash or System.exit called > ? -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please > read the following articles: > [ERROR] [Help 1] > http://cwiki.
[jira] (SUREFIRE-836) regression with surefire 2.12 plugin and SecurityManager
[ https://jira.codehaus.org/browse/SUREFIRE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291770#comment-291770 ] Henning Schmiedehausen commented on SUREFIRE-836: - No, the TestPostgresUtils does not. That is why you should run it with -Dtest=TestPostgresUtils If you do have a local postgres that allows connection as postgres user without a password, then all tests can be run. The result is the same, though. > regression with surefire 2.12 plugin and SecurityManager > > > Key: SUREFIRE-836 > URL: https://jira.codehaus.org/browse/SUREFIRE-836 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12 > Environment: mvn --version > Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: /home/henning/.mvn > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.30/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.34.9-69.fc13.x86_64", arch: "amd64", family: > "unix" > (also with maven 3.0.3) >Reporter: Henning Schmiedehausen > > We are running all our tests using a special security manager that restricts > IO in tests. There is a regression when running these tests with the 2.12 > plugin compared to the 2.11 plugin: > How to reproduce: > 1) git clone g...@github.com:NessComputing/components-ness-pg.git > 2) mvn clean compile test-compile > 3) Run the tests with the 2.11 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.11:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.11:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > 2012-02-14 15:15:06,823 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:77): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > 4) Run the tests with the 2.12 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.12:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.12:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec > Z,0,BYE! > 2012-02-14 15:15:32,233 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:79): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.334s > [INFO] Finished at: Tue Feb 14 15:15:32 PST 2012 > [INFO] Final Memory: 5M/181M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-cli) on > project ness-pg: Execution default-cli of goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test failed: The forked > VM terminated without saying properly goodbye. VM crash or System.exit called > ? -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Ma
[jira] (MRELEASE-550) Version incrementation in non interactive release (batch-mode / -B)
[ https://jira.codehaus.org/browse/MRELEASE-550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-550: Component/s: prepare > Version incrementation in non interactive release (batch-mode / -B) > --- > > Key: MRELEASE-550 > URL: https://jira.codehaus.org/browse/MRELEASE-550 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.1 > Environment: Windows 7, jdk1.6.0_17 >Reporter: Christian Moser > Attachments: devVersionIncrementation_v2.patch, > versionIncrementation.patch > > > This feature makes it possible to configure the incrementation process in > batch-mode. > As default the release plugin increments the patch-level digit and adds > -SNAPSHOT after a release has been executed. e,g > 1.3.3-SNAPSHOT --> 1.3.3 --> *1.3.4-SNAPSHOT* > With the following feature, the user will be allowed by setting a property in > the release:prepare goal to change this behavior > -DdevVersionIncrementation=2 > 1.3.3-SNAPSHOT --> 1.3.3 --> *1.4.0-SNAPSHOT* > or (-DdevVersionIncrementation=1) > 1.3.3-SNAPSHOT --> 1.3.3 --> *2.0.0-SNAPSHOT* > the default value is -DdevVersionIncrementation=3 and will increment the > patch-level digit as usual. > In the attachment you'll find a patch for the fully implemented feature, I'd > very thankful if someone could insert it into the next version. -- 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] (MWAR-274) Add support for mavenFilteringHints
Eric Dalquist created MWAR-274: -- Summary: Add support for mavenFilteringHints Key: MWAR-274 URL: https://jira.codehaus.org/browse/MWAR-274 Project: Maven 2.x WAR Plugin Issue Type: Improvement Components: filtering Affects Versions: 2.1.1 Reporter: Eric Dalquist It would be really handy if the war plugin supported the execution of additional MavenResourcesFiltering instances via the mavenFilteringHints API I'm looking through the maven-war-plugin source right now to see if an approach for this is obvious and I'll supply a patch if I figured something out. -- 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-836) regression with surefire 2.12 plugin and SecurityManager
[ https://jira.codehaus.org/browse/SUREFIRE-836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed SUREFIRE-836. --- Resolution: Fixed Fix Version/s: 2.13 Assignee: Kristian Rosenvold Thanks for the problem report ! Fixed with IT in r1244625 > regression with surefire 2.12 plugin and SecurityManager > > > Key: SUREFIRE-836 > URL: https://jira.codehaus.org/browse/SUREFIRE-836 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12 > Environment: mvn --version > Apache Maven 3.0.4 (r1232337; 2012-01-17 00:44:56-0800) > Maven home: /home/henning/.mvn > Java version: 1.6.0_30, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.30/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.34.9-69.fc13.x86_64", arch: "amd64", family: > "unix" > (also with maven 3.0.3) >Reporter: Henning Schmiedehausen >Assignee: Kristian Rosenvold > Fix For: 2.13 > > > We are running all our tests using a special security manager that restricts > IO in tests. There is a regression when running these tests with the 2.12 > plugin compared to the 2.11 plugin: > How to reproduce: > 1) git clone g...@github.com:NessComputing/components-ness-pg.git > 2) mvn clean compile test-compile > 3) Run the tests with the 2.11 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.11:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.11:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.064 sec > 2012-02-14 15:15:06,823 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:77): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD SUCCESS > [INFO] > > 4) Run the tests with the 2.12 plugin: > mvn -Dtest=TestPostgresUtils > org.apache.maven.plugins:maven-surefire-plugin:2.12:test > [INFO] Scanning for projects... > [INFO] > > [INFO] > > [INFO] Building ness-pg 2.0.1-SNAPSHOT > [INFO] > > [INFO] > [INFO] --- maven-surefire-plugin:2.12:test (default-cli) @ ness-pg --- > [INFO] Surefire report directory: > /home/scratch/components-ness-pg/target/surefire-reports > --- > T E S T S > --- > Running com.nesscomputing.db.TestPostgresUtils > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec > Z,0,BYE! > 2012-02-14 15:15:32,233 INFO main > com.nesscomputing.testing.lessio.LessIOSecurityManager > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:79): > exit(0) > Results : > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 2.334s > [INFO] Finished at: Tue Feb 14 15:15:32 PST 2012 > [INFO] Final Memory: 5M/181M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test (default-cli) on > project ness-pg: Execution default-cli of goal > org.apache.maven.plugins:maven-surefire-plugin:2.12:test failed: The forked > VM terminated without saying properly goodbye. VM crash or System.exit called > ? -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e > switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information
[jira] (SUREFIRE-837) Surefire 2.12 fails after first module
[
https://jira.codehaus.org/browse/SUREFIRE-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291779#comment-291779
]
Kristian Rosenvold commented on SUREFIRE-837:
-
SUREFIRE-836 was just fixed, and I see you're mentioning a security manager.
Care to test 2.13-SNAPSHOT and see if it fixes the problem ?
> Surefire 2.12 fails after first module
> --
>
> Key: SUREFIRE-837
> URL: https://jira.codehaus.org/browse/SUREFIRE-837
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: Maven 3.0.4, surefire 2.12, JUnit 4.10, JDK1.6_30, WinXP
>Reporter: François LEIBER
> Attachments: surefire2.12.log
>
>
> We have a big issue with surefire 2.12 (using default configuration, which
> means forkMode=once): the Junit tests of the first module pass perfectly,
> then we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
> {code}
> The forked VM terminated without saying properly goodbye. VM crash or
> System.exit called ?
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
> {code}
> It seems related to the following code, taken from
> maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java:
> {code}
> runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
> providerConfiguration );
> // Say bye.
> System.out.println("Z,0,BYE!");
> System.out.flush();
> // noinspection CallToSystemExit
> System.exit( 0 );
> {code}
> This happens at every run, just reverting surefire to 2.11 fixes the issue.
> If I use forkMode=never, it works, but our code needs a forked VM, otherwise
> we have SecurityManager issues.
> The surefire configuration itself is very basic:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.12
>
> -Xms128m -Xmx1024m
>
> **/SelfHostingTests.java
>
>
>
> {code}
> Attached is the full build log with -X.
--
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-837) Surefire 2.12 fails after first module
[
https://jira.codehaus.org/browse/SUREFIRE-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291781#comment-291781
]
François LEIBER commented on SUREFIRE-837:
--
OK I'll test it.
> Surefire 2.12 fails after first module
> --
>
> Key: SUREFIRE-837
> URL: https://jira.codehaus.org/browse/SUREFIRE-837
> Project: Maven Surefire
> Issue Type: Bug
>Affects Versions: 2.12
> Environment: Maven 3.0.4, surefire 2.12, JUnit 4.10, JDK1.6_30, WinXP
>Reporter: François LEIBER
> Attachments: surefire2.12.log
>
>
> We have a big issue with surefire 2.12 (using default configuration, which
> means forkMode=once): the Junit tests of the first module pass perfectly,
> then we have a "Z,0,BYE!" in the log and the surefire plugin fails with:
> {code}
> The forked VM terminated without saying properly goodbye. VM crash or
> System.exit called ?
> at
> org.apache.maven.plugin.surefire.booterclient.output.ForkClient.close(ForkClient.java:244)
> {code}
> It seems related to the following code, taken from
> maven/surefire/trunk/surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java:
> {code}
> runSuitesInProcess( testSet, testClassLoader, startupConfiguration,
> providerConfiguration );
> // Say bye.
> System.out.println("Z,0,BYE!");
> System.out.flush();
> // noinspection CallToSystemExit
> System.exit( 0 );
> {code}
> This happens at every run, just reverting surefire to 2.11 fixes the issue.
> If I use forkMode=never, it works, but our code needs a forked VM, otherwise
> we have SecurityManager issues.
> The surefire configuration itself is very basic:
> {code}
>
> org.apache.maven.plugins
> maven-surefire-plugin
> 2.12
>
> -Xms128m -Xmx1024m
>
> **/SelfHostingTests.java
>
>
>
> {code}
> Attached is the full build log with -X.
--
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-5246) Allow inside element
Martin Desruisseaux created MNG-5246:
Summary: Allow inside element
Key: MNG-5246
URL: https://jira.codehaus.org/browse/MNG-5246
Project: Maven 2 & 3
Issue Type: Improvement
Components: Plugins and Lifecycle
Affects Versions: 3.0.4
Environment: All
Reporter: Martin Desruisseaux
Priority: Minor
In the current Maven project descriptor
(http://maven.apache.org/ref/3.0.4/maven-model/maven.html), plugins are
declared inside {{}} elements by specifying the {{}},
{{}} and {{}} elements. However the {{}}
element is currently not legal for a plugin. I would like {{}} to
be legal for plugins, like any other dependencies.
*Use case:* I maintain two branches for my project: a development branch on
JDK7, and a branch ported to JDK6. I use custom Maven plugins for my build
process. However the JDK7 doclet API seems to have some incompatible changes
compared to the JDK6 doclet API. In addition some APT (Annotation Processing
Tools) API are being removed from JDK8, since they are now merged with the
javac API. For various reasons (may also be reasons specific to my projects), I
wish slightly different Maven plugins depending if I'm building my JDK6 branch
or my JDK7 branch. I would like to simply use my custom Maven plugins with the
same classifier than the project I'm building, but this is currently not
possible.
--
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-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-723: Patch Submitted: Yes Testcase included: yes > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen > Fix For: 2.3 > > Attachments: add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- 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-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MRELEASE-723: Component/s: Git > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen > Fix For: 2.3 > > Attachments: add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- 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-734) When releaseVersion and developmentVersion are passed in command-line but are empty should be treated as not-defined
[
https://jira.codehaus.org/browse/MRELEASE-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MRELEASE-734:
Component/s: prepare
> When releaseVersion and developmentVersion are passed in command-line but are
> empty should be treated as not-defined
>
>
> Key: MRELEASE-734
> URL: https://jira.codehaus.org/browse/MRELEASE-734
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: prepare
>Affects Versions: 2.2.2
>Reporter: Dmitry Katsubo
>
> In my case I would like to pass {{releaseVersion}} and {{developmentVersion}}
> taken from user input, e.g. from [Hudson Release
> Plugin|http://wiki.hudson-ci.org/display/HUDSON/Release+Plugin]:
> {code}
> release:prepare release:perform -DreleaseVersion=${RELEASE_VERSION}
> -DdevelopmentVersion=${DEVELOPMENT_VERSION}
> {code}
> however if user leaves input fields empty it would be nice if
> maven-release-plugin would treat empty values as non-defined and fallback to
> default behaviour: inherit the next version from pom. Currently it breaks
> down with message 'Unable to parse the version string ""'.
--
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-723) DCVS tagging commands should store the tag-name (or hash) in the the //project/scm/tag element.
[ https://jira.codehaus.org/browse/MRELEASE-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291822#comment-291822 ] Mirko Friedenhagen commented on MRELEASE-723: - @Robert: the patch is for Mercurial and Subversion as well, could you adapt the components? > DCVS tagging commands should store the tag-name (or hash) in the the > //project/scm/tag element. > --- > > Key: MRELEASE-723 > URL: https://jira.codehaus.org/browse/MRELEASE-723 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: Git > Environment: Apache Maven 3.0.4-RC3 (r1210461; 2011-12-05 > 14:58:54+0100) > Maven home: /usr/local/Cellar/maven/current/libexec > Java version: 1.6.0_29, vendor: Apple Inc. > Java home: > /Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home > Default locale: de_DE, platform encoding: MacRoman > OS name: "mac os x", version: "10.7.2", arch: "x86_64", family: "mac" >Reporter: Mirko Friedenhagen > Fix For: 2.3 > > Attachments: add-tag-to-release-poms.patch > > > With SVN the developerConnection and connection are > updated to the "real" release URL, that is when I invoke release:prepare with > a URL like: > https://SVNSERVER/svn/REPO/myproject/branches/release it will be > replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 > which is fine because now you know which revision to checkout for > building the release. > With git there is no such possibility to realize this with rewriting > the URL AFAIK. So I would have expected however, that maybe the > //project/scm/tag > element would be updated to reflect the fact, that the pom is the one > of release, either to the "symbolic name" myproject-1.0 or to the hash > of the tag. > See http://markmail.org/thread/m77cvhqqq56krzzd as well. -- 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-600) ModuleSets incorrectly detected with useAllReactorProjects while aggregating modules with parents differing from the aggregator
José Pedro Pereira created MASSEMBLY-600:
Summary: ModuleSets incorrectly detected with
useAllReactorProjects while aggregating modules with parents differing from the
aggregator
Key: MASSEMBLY-600
URL: https://jira.codehaus.org/browse/MASSEMBLY-600
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.3, 2.2.2, 2.2
Environment: Maven 2.2.1
Reporter: José Pedro Pereira
Priority: Blocker
Attachments: child-aggregator.zip
In two multi-module project setups like the ones attached to the bug where:
root-aggregator (type=pom -> aggregator as well as extension)
|
|___(module)___ root-type1 (type=pom -> only for extension)
|
|___(module)___ assembler (type=pom -> uses maven-assembly-plugin with
shared-assembly-defs dependency)
|
|___(module)___ shared-assembly-defs (type=jar)
|
|/src/main/resources/assemblies/assemblydefinition.xml
|
| moduleSets ->
moduleSet (useAllReactorProjects=true) -> binaries
and another multi-module project with these characteristics:
child-aggregator (parent=root-aggregator for inheritance)
|
|(module)___ child-assembler (parent=root.assembler for inheritance of
maven-assembly-plugin)
|
|(module)___ child-type1 (parent=root-type1 for inheritance of
dependencies and plugins config)
The assembly zip in the child-aggregator/child-assembler project does not
contain the jar from child-type1 even though it is in the reactor projects
list...
I was able to trace the problem back to the class:
org.apache.maven.plugin.assembly.archive.phase.ModuleSetAssemblyPhase
method:
public static Set getModuleProjects( final ModuleSet moduleSet,
final
AssemblerConfigurationSource configSource,
final Logger logger )
where the code reads:
if ( moduleSet.isUseAllReactorProjects() ) <--- we are in this case
because our assembly descriptor says so!
{
if ( !moduleSet.isIncludeSubModules() ) <-- In the case that shows
the bug this is not defined - default is true
{
moduleProjects = new LinkedHashSet(
configSource.getReactorProjects() );
}
project = configSource.getReactorProjects().get( 0 ); <-- first
project in the reactor order gets chosen... why?
}
if ( moduleProjects == null )
{
try
{
moduleProjects =
ProjectUtils.getProjectModules( project,
configSource.getReactorProjects(),
moduleSet.isIncludeSubModules(), logger );
<-- here if finds all modules of "first in the reactor"
project
}
catch ( final IOException e )
{
throw new ArchiveCreationException( "Error retrieving
module-set for project: " + project.getId()
+ ": " + e.getMessage(), e );
}
}
If on the other hand (for working around the issue) one sets
includeSubModules=false in the assembly definition (just uncomment in the
"assembly-share" project assembly definition in the submitted example), then
the reactor projects are used as per the top aggregator and everything goes
well, except for the fact that another warning shows up saying that
includeSubModules=false and useAllReactorProjects=true are incompatible and
will be ignored (this combination is not ignored but the warning does make
sense, though!)
This is related to the fact that in the child-aggregator project and modules,
there is no dependency between the child-type1 project and the
child-aggregator, which means the Reactor will order the builds as
child-type1, child-assembler, child-aggregator
but the code actually selects child-type1 as the "project" to determine modules
from.
--
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] (MJAR-139) New option to avoid empty jar creation
[ https://jira.codehaus.org/browse/MJAR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=291849#comment-291849 ] Roman Ivanov commented on MJAR-139: --- works fine, thanks for patch config to use: org.apache.maven.plugins maven-jar-plugin 2.4 true test-jar > New option to avoid empty jar creation > -- > > Key: MJAR-139 > URL: https://jira.codehaus.org/browse/MJAR-139 > Project: Maven 2.x JAR Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 >Reporter: Roman Ivanov >Assignee: Kristian Rosenvold > Fix For: 2.4 > > Attachments: MJAR-139.patch > > > Usage of "test-jar" is beneficial for all project, as all of them have tests. > > org.apache.maven.plugins > maven-jar-plugin > 2.3.1 > > > > test-jar > > > > > Pom artifacts and some jar artifacts does not have test and will never have > them. > In logs we have: "[WARNING] JAR will be empty - no content was marked for > inclusion!" > and empty and useless artifacts are created, deployed , ... > It will be convenient to have an plugin option to define whether skip empty > jar creation and warning or generate jar with warning in log. Does it make > sense ? > By default option will be FALSE, to comply with previous behavior. -- 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] (MJAVADOC-342) An incomplete fix for the NPE bugs in AbstractJavadocMojo.java
Guangtai Liang created MJAVADOC-342: --- Summary: An incomplete fix for the NPE bugs in AbstractJavadocMojo.java Key: MJAVADOC-342 URL: https://jira.codehaus.org/browse/MJAVADOC-342 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Reporter: Guangtai Liang Priority: Critical The fix revision 554202 was aimed to remove an NPE bug on the returned value of "getJavadocDirectory()" in the method "getSourcePaths " of the file "/maven/plugins/trunk/maven-javadoc-plugin/src/main/java/org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java" , but it is incomplete. Since the returned value "getJavadocDirectory()" could be null during the runtime execution, its value should also be null-checked before being dereferenced in other methods. The buggy code locations the same fix needs to be applied at are as bellows: Line 2401 of the method "copyJavadocResources"; Line 1505 of the method "getSourcePaths". -- 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] (MWAR-275) An incomplete fix for the NPE bugs in WebappStructure.java
Guangtai Liang created MWAR-275:
---
Summary: An incomplete fix for the NPE bugs in WebappStructure.java
Key: MWAR-275
URL: https://jira.codehaus.org/browse/MWAR-275
Project: Maven 2.x WAR Plugin
Issue Type: Bug
Reporter: Guangtai Liang
Priority: Critical
The fix revision 712569 was aimed to remove an NPE bug on the value of
"dependenciesInfo " in the method "getDependencies" of the file
"/maven/plugins/trunk/maven-war-plugin/src/main/java/org/apache/maven/plugin/war/util/WebappStructure.java"
, but it is incomplete.
Since the value "dependenciesInfo " could be null during the runtime
execution, its value should also be null-checked before being dereferenced in
other methods.
The buggy code locations the same fix needs to be applied at are as bellows:
Line 389 of the method "registerTargetFileName";
public void registerTargetFileName( Artifact artifact, String targetFileName )
{
[Line 389] final Iterator it = dependenciesInfo.iterator();
while ( it.hasNext() )
{
DependencyInfo dependencyInfo = (DependencyInfo) it.next();
if ( WarUtils.isRelated( artifact, dependencyInfo.getDependency() )
)
{
dependencyInfo.setTargetFileName( targetFileName );
}
}
}
--
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
