Forked executor closes caller-supplied stdout and stderr streams

Start in maven-executor/src/main/java/org/apache/maven/executor/support/ProcessBuilderExecutorSupport.java at lines 124 and 137, then compare stream handling in EmbeddedMavenExecutor.java at lines 293-294. Trace ExecutorRequest.Builder.stdOut() and stdErr() to confirm the ownership contract. Done means caller-supplied streams are flushed without being closed, shared stdout/stderr streams work, and the ownership behavior is documented.

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), 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) 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.