You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Tom Baeyens (JIRA)" <ji...@codehaus.org> on 2010/12/14 09:59:57 UTC
[jira] Created: (SUREFIRE-665) Output to file stops after a while
Output to file stops after a while
----------------------------------
Key: SUREFIRE-665
URL: http://jira.codehaus.org/browse/SUREFIRE-665
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.6
Reporter: Tom Baeyens
After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
My environment: Mac with
Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
Using Surefire 2.6
I've done following observations:
* The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
* When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
* The problem doesn't occur when running the same test suite in eclipse.
* When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
* Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
* I traced closing of the system err stream until SystemStreamCapturer
76 public void restoreStreams()
77 {
78 // Note that the fields can be null if the test hasn't even started yet (an early error)
79 if ( oldOut != null )
80 {
81 System.setOut( oldOut );
82 }
83 if ( oldErr != null )
84 {
85 System.setErr( oldErr );
86 }
87
88 IOUtil.close( newOut );
89 IOUtil.close( newErr );
90 }
But there I couldn't find how to trace it further and gave up.
To reproduce: (only tested on mac)
check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
mvn clean install
only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-665) Output to file stops after a while
Posted by "Kristian Rosenvold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Rosenvold updated SUREFIRE-665:
----------------------------------------
Fix Version/s: (was: 2.7.1)
2.7
> Output to file stops after a while
> ----------------------------------
>
> Key: SUREFIRE-665
> URL: http://jira.codehaus.org/browse/SUREFIRE-665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.6
> Reporter: Tom Baeyens
> Assignee: Kristian Rosenvold
> Fix For: 2.7
>
>
> After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
> My environment: Mac with
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
> Using Surefire 2.6
> I've done following observations:
> * The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
> * When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
> * The problem doesn't occur when running the same test suite in eclipse.
> * When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
> * Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
> * I traced closing of the system err stream until SystemStreamCapturer
> 76 public void restoreStreams()
> 77 {
> 78 // Note that the fields can be null if the test hasn't even started yet (an early error)
> 79 if ( oldOut != null )
> 80 {
> 81 System.setOut( oldOut );
> 82 }
> 83 if ( oldErr != null )
> 84 {
> 85 System.setErr( oldErr );
> 86 }
> 87
> 88 IOUtil.close( newOut );
> 89 IOUtil.close( newErr );
> 90 }
> But there I couldn't find how to trace it further and gave up.
> To reproduce: (only tested on mac)
> check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
> mvn clean install
> only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-665) Output to file stops after a while
Posted by "Kristian Rosenvold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247661#action_247661 ]
Kristian Rosenvold commented on SUREFIRE-665:
---------------------------------------------
Could you try this with the 2.7-SNAPSHOT that is out now ? This should be fixed in 2.7
> Output to file stops after a while
> ----------------------------------
>
> Key: SUREFIRE-665
> URL: http://jira.codehaus.org/browse/SUREFIRE-665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.6
> Reporter: Tom Baeyens
>
> After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
> My environment: Mac with
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
> Using Surefire 2.6
> I've done following observations:
> * The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
> * When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
> * The problem doesn't occur when running the same test suite in eclipse.
> * When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
> * Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
> * I traced closing of the system err stream until SystemStreamCapturer
> 76 public void restoreStreams()
> 77 {
> 78 // Note that the fields can be null if the test hasn't even started yet (an early error)
> 79 if ( oldOut != null )
> 80 {
> 81 System.setOut( oldOut );
> 82 }
> 83 if ( oldErr != null )
> 84 {
> 85 System.setErr( oldErr );
> 86 }
> 87
> 88 IOUtil.close( newOut );
> 89 IOUtil.close( newErr );
> 90 }
> But there I couldn't find how to trace it further and gave up.
> To reproduce: (only tested on mac)
> check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
> mvn clean install
> only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-665) Output to file stops after a while
Posted by "Kristian Rosenvold (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Rosenvold closed SUREFIRE-665.
---------------------------------------
Resolution: Fixed
Fix Version/s: 2.7.1
Assignee: Kristian Rosenvold
Fixed in r1049669. It's the redirectOutputToFile that is buggy and can have race conditions.
> Output to file stops after a while
> ----------------------------------
>
> Key: SUREFIRE-665
> URL: http://jira.codehaus.org/browse/SUREFIRE-665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.6
> Reporter: Tom Baeyens
> Assignee: Kristian Rosenvold
> Fix For: 2.7.1
>
>
> After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
> My environment: Mac with
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
> Using Surefire 2.6
> I've done following observations:
> * The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
> * When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
> * The problem doesn't occur when running the same test suite in eclipse.
> * When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
> * Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
> * I traced closing of the system err stream until SystemStreamCapturer
> 76 public void restoreStreams()
> 77 {
> 78 // Note that the fields can be null if the test hasn't even started yet (an early error)
> 79 if ( oldOut != null )
> 80 {
> 81 System.setOut( oldOut );
> 82 }
> 83 if ( oldErr != null )
> 84 {
> 85 System.setErr( oldErr );
> 86 }
> 87
> 88 IOUtil.close( newOut );
> 89 IOUtil.close( newErr );
> 90 }
> But there I couldn't find how to trace it further and gave up.
> To reproduce: (only tested on mac)
> check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
> mvn clean install
> only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-665) Output to file stops after a while
Posted by "Tom Baeyens (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247818#action_247818 ]
Tom Baeyens commented on SUREFIRE-665:
--------------------------------------
The results with 2.7-SNAPSHOT are different, but still not OK.
The first -output.txt files --this time in alfabetical order-- now contain the logging. The last file that contains logging is a big one (4,051,585 bytes)
Console output:
...
Running org.activiti.standalone.initialization.ProcessEnginesTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.255 sec
Running org.activiti.standalone.interceptor.CommandContextTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.238 sec
Results :
Tests run: 465, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:41)
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.apache.maven.plugin.MojoExecutionException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:614)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
... 17 more
Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error while executing forked tests.; nested exception is org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:227)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnce(ForkStarter.java:118)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:102)
at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:600)
... 19 more
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:227)
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:223)
... 22 more
Caused by: java.lang.NullPointerException
at org.apache.maven.plugin.surefire.booterclient.output.FileOutputConsumerProxy.consumeOutputLine(FileOutputConsumerProxy.java:125)
at org.apache.maven.plugin.surefire.booterclient.ForkingStreamConsumer.consumeLine(ForkingStreamConsumer.java:75)
at org.codehaus.plexus.util.cli.StreamPumper.consumeLine(StreamPumper.java:197)
at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:137)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 8 seconds
[INFO] Finished at: Wed Dec 15 09:35:44 CET 2010
[INFO] Final Memory: 48M/528M
[INFO] ------------------------------------------------------------------------
> Output to file stops after a while
> ----------------------------------
>
> Key: SUREFIRE-665
> URL: http://jira.codehaus.org/browse/SUREFIRE-665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.6
> Reporter: Tom Baeyens
>
> After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
> My environment: Mac with
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
> Using Surefire 2.6
> I've done following observations:
> * The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
> * When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
> * The problem doesn't occur when running the same test suite in eclipse.
> * When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
> * Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
> * I traced closing of the system err stream until SystemStreamCapturer
> 76 public void restoreStreams()
> 77 {
> 78 // Note that the fields can be null if the test hasn't even started yet (an early error)
> 79 if ( oldOut != null )
> 80 {
> 81 System.setOut( oldOut );
> 82 }
> 83 if ( oldErr != null )
> 84 {
> 85 System.setErr( oldErr );
> 86 }
> 87
> 88 IOUtil.close( newOut );
> 89 IOUtil.close( newErr );
> 90 }
> But there I couldn't find how to trace it further and gave up.
> To reproduce: (only tested on mac)
> check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
> mvn clean install
> only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-665) Output to file stops after a while
Posted by "Tom Baeyens (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/SUREFIRE-665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=247587#action_247587 ]
Tom Baeyens commented on SUREFIRE-665:
--------------------------------------
currently in the activiti svn, no version of surefire is configured. on my system it was using 2.4.something. but also when I configured 2.6 the problem persisted (and also I got an extra out of memory problem)
> Output to file stops after a while
> ----------------------------------
>
> Key: SUREFIRE-665
> URL: http://jira.codehaus.org/browse/SUREFIRE-665
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.6
> Reporter: Tom Baeyens
>
> After some tests of proper behavior, surefire stops logging the console output (stderr & stdout) to the files. For the first tests that are executed, the Xxxxx-output.txt files contain the correct console output. But from some test in the test suite, all those files are blank.
> My environment: Mac with
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01-279, mixed mode)
> Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
> Using Surefire 2.6
> I've done following observations:
> * The exact test where the console capturing stops can vary a couple of tests, but it always happens. Could it be related to memory? Increasing from MAVEN_OPTS="-Xmx1024m -Xms512m" to MAVEN_OPTS="-Xmx2048m -Xms512m" didn't have an effect
> * When debugging, as long as the output is ok, System.err.checkError() returns false. Once the output files get blank, System.err.checkError() returns true.
> * The problem doesn't occur when running the same test suite in eclipse.
> * When I didn't specify surefire version, I got 2.4.something. When I explicitely set the version to 2.6, then the test suite started failing half way with out of memory exceptions.
> * Then I configured <forkMode>always</forkMode>. That made the whole test suite run fine (no memory exceptions and all log files being produced) but then it takes a very long time.
> * I traced closing of the system err stream until SystemStreamCapturer
> 76 public void restoreStreams()
> 77 {
> 78 // Note that the fields can be null if the test hasn't even started yet (an early error)
> 79 if ( oldOut != null )
> 80 {
> 81 System.setOut( oldOut );
> 82 }
> 83 if ( oldErr != null )
> 84 {
> 85 System.setErr( oldErr );
> 86 }
> 87
> 88 IOUtil.close( newOut );
> 89 IOUtil.close( newErr );
> 90 }
> But there I couldn't find how to trace it further and gave up.
> To reproduce: (only tested on mac)
> check out https://svn.codehaus.org/activiti/activiti/trunk and then on the root do
> mvn clean install
> only the first executed tests will contain properly captured output in modules/activiti-engine/target/surefire-reports/*-output.txt
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira