[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17311608#comment-17311608
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 3/30/21, 4:05 PM:
-------------------------------------------------------------------------
[~tibordigana], how long ago did you clone the repository? In the current
master which I pushed 14 hours ago, there is no Java agent anymore. You must
have used an older version and for the 5th time or so not done what I told you
to: to *deactivate the agent* (or just use current master in which I have done
it for you already) in order to focus on the problem which is certainly *not*
caused by the agent.
How difficult is it to follow my advice? Is it like my words are non-existent
for you? Did you put my posts on a spam filter or so? I cannot believe you are
still doing the same as before, even after I told you so many times that *you
do not need any agents* in order to reproduce this problem.
Your log output proves that you use the agent, chasing ghosts instead of
focusing on the actual problem. Maybe you fix that one first. Then
*_afterwards,_* if it works without the agent but then another problem still
persists when switching back to the agent on the other repository branch, we
can focus on that one. Why not start simple and do the more complex stuff
afterwards?
*Edit:* BTW, we do not have a Java policy file problem on *Java 11* here
because the build also hangs on *Java 8* and all other Java versions I tested,
like I already told you long ago.
was (Author: kriegaex):
[~tibordigana], how long ago did you clone the repository? In the current
master which I pushed 14 hours ago, there is no Java agent anymore. You must
have used an older version and for the 5th time or so not done what I told you
to: to *deactivate the agent* (or just use current master in which I have done
it for you already) in order to focus on the problem which is certainly *not*
caused by the agent.
How difficult is it to follow my advice? Is it like my words are non-existent
for you? Did you put my posts on a spam filter or so? I cannot believe you are
still doing the same as before, even after I told you so many times that *you
do not need any agents* in order to reproduce this problem.
Your log output proves that you use the agent, chasing ghosts instead of
focusing on the actual problem. Maybe you fix that one first. Then
*_afterwards,_* if it works without the agent but then another problem still
persists when switching back to the agent on the other repository branch, we
can focus on that one. Why not start simple and do the more complex stuff
afterwards?
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> ------------------------------------------------------------------------------------------
>
> Key: SUREFIRE-1881
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1881
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
> Affects Versions: 3.0.0-M5
> Reporter: Alexander Kriegisch
> Assignee: Tibor Digana
> Priority: Major
> Attachments: Bildschirmfoto von 2021-03-29 21-50-25.png,
> image-2021-02-08-12-07-34-183.png, image-2021-03-26-09-48-11-398.png,
> image-2021-03-26-09-52-36-881.png, image-2021-03-26-18-00-37-889.png,
> maven-failsafe-debug-log.txt, screenshot-1.png
>
>
> This is a follow-up to SUREFIRE-1788 which was closed prematurely even though
> there still were open issues which were discussed there initially. Basically
> the situation is as follows:
> * I use Java agents writing to stdOut and stdErr in my tests.
> * I was annoyed that Surefire/Failsafe were writing lots of {{[WARNING]
> Corrupted STDOUT by directly writing to native stream in forked JVM}} lines
> into {{*-jvmRun1.dumpstream}} files. [~tibordigana] then told me to use
> {{<forkNode
> implementation="org.apache.maven.plugin.surefire.extensions.SurefireForkNodeFactory"/>}}
> in my POM in order to fix the issue.
> * I tried this in version 3.0.0-M5, but unfortunately, it makes
> Surefire/Failsafe freeze if a Java agent prints something to stdOut or
> stdErr. This happens both in M5 and in M6-SNAPSHOT after both SUREFIRE-1788
> and SUREFIRE-1809 have been merged in already.
> * My [sample
> project|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems]
> reproduces the issue as soon as you uncomment the option in the POM and run
> {{mvn clean verify}}.
> * The second issue is: *Not* using this option leads to garbled log output
> when a Java agent writes to both stdOut and stdErr before/during tests. See
> comments in class
> [{{Agent.DummyTransformer}}|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/src/main/java/de/scrum_master/dummy/Agent.java]
> for examples for garbled log lines and also comments in
> [pom.xml|https://github.com/kriegaex/Maven_Surefire_PrintToConsoleProblems/blob/master/pom.xml#L36]
> for further information.
> * If the garbled output would also appear with this option activated, cannot
> be tested at present due to the Surefire/Failsafe freeze. I will re-test that
> after the freeze has been fixed and before this issue can be closed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
