[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477104#comment-17477104
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 1/17/22, 10:22 AM:
--------------------------------------------------------------------------
[~tibordigana], I was not so much surprised that the master can be unstable but
that non-master snapshots which seem to contain old bugs long merged into
master are deployed to a publicly available snapshot repository. I.e., you have
master and non-master snapshots overwriting each other. Actually, when running
my tests, I do not want to make an appointment for a "stable master". Too much
work for you guys and too much coordination on both sides. I simply was
expecting each snapshot to actually be a master.
Like I said, the master itself is OK, I built it locally and it works. It
simply gets overwritten by newer snapshots from the public snapshot repo (some
of them non-master), as soon as they are deployed.
Maybe I actually have to build a non-snapshot version with a self-invented
version number in order to keep it stable. But then OTOH, I shall never notice
if there are more recent master versions to be tested.
Thank you so much for the explanation. Now I know that I cannot rely on
snapshots to be from master. Maybe you should think about this policy, because
it affects all consumers of snapshot versions, both Surefire developers and
users. Maybe stuff from non-master branches should not be deployed to a public
repo.
was (Author: kriegaex):
[~tibordigana], I was not so much surprised that the master can be unstable but
that non-master snapshots which seem to contain old bugs long merged into
master are deployed to a publicly available snapshot repository. I.e., you have
master and non-master snapshots overwriting each other. Actually, when running
my tests, I do not want to make an appointment for a "stable master". Too much
work for you guys and too much coordination on both sides. I simply was
expecting each snapshot to actually be a master.
Like I said, the master itself is OK, I built it locally and it works. It
simply gets overwritten by newer snapshots from the public snapshot repo (some
of them non-master), as soon as they are deployed.
Maybe I actually have to build a non-snapshot version with a self-invented
version number in order to keep it stable. But then OTOH, I shall never notice
if there are more recent master versions to be tested.
Thank you so much for the explanation. Now I know that I cannot rely on
snapshots to be from master.
> 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
> Fix For: 3.0.0-M6
>
> 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,
> image-2021-03-31-11-22-50-682.png, image-2021-03-31-11-38-11-119.png,
> image-2021-03-31-12-31-55-818.png, image-2021-03-31-12-32-41-589.png,
> maven-failsafe-debug-log.txt, screenshot-1.png, screenshot-2.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.20.1#820001)
