slachiewicz opened a new issue, #45: URL: https://github.com/apache/maven-executor/issues/45
### Affected version 1.0.0 ### Bug description `ForkedMavenExecutor` closes the `OutputStream` instances a caller passes through `ExecutorRequest.Builder.stdOut()` and `stdErr()`. Each pump thread wraps the stream in try-with-resources ([ProcessBuilderExecutorSupport.java:124,137](https://github.com/apache/maven-executor/blob/main/maven-executor/src/main/java/org/apache/maven/executor/support/ProcessBuilderExecutorSupport.java)), so: - A caller that hands the same stream to both `stdOut()` and `stdErr()` to get one interleaved log, as `maven-verifier` produced, gets two threads racing to close it, and the second `transferTo` can fail with a closed stream. - A caller that passes `System.out` or a stream it intends to keep using loses it after the first execution. - `EmbeddedMavenExecutor` wraps the same streams in `PrintStream` instances ([EmbeddedMavenExecutor.java:293-294](https://github.com/apache/maven-executor/blob/main/maven-executor/src/main/java/org/apache/maven/executor/embedded/EmbeddedMavenExecutor.java)) and does not close them, so the two executors treat ownership differently. Found while porting `maven-integration-testing` and `maven-surefire`'s IT fixtures from maven-verifier (apache/maven-verifier#186); both now wrap the log file in a stream with an idempotent `close()`. Proposal: the executor should not close streams it did not open. Flush them after the pump finishes and leave closing to the caller, and document that `stdOut()` and `stdErr()` may be the same stream. If closing has to stay for compatibility, document it in `ExecutorRequest.Builder` Javadoc. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
