[GitHub] [maven-invoker-plugin] dependabot[bot] opened a new pull request #35: Bump actions/cache from v2 to v2.1.4
dependabot[bot] opened a new pull request #35: URL: https://github.com/apache/maven-invoker-plugin/pull/35 Bumps [actions/cache](https://github.com/actions/cache) from v2 to v2.1.4. Release notes Sourced from https://github.com/actions/cache/releases;>actions/cache's releases. v2.1.4 Make caching more verbose https://github-redirect.dependabot.com/actions/toolkit/pull/650;>#650 Use GNU tar on macOS if available https://github-redirect.dependabot.com/actions/toolkit/pull/701;>#701 Commits https://github.com/actions/cache/commit/26968a09c0ea4f3e233fdddbafd1166051a095f6;>26968a0 Make save/restore logs akin (https://github-redirect.dependabot.com/actions/cache/issues/509;>#509) https://github.com/actions/cache/commit/aeaf731ae27476fbdef0ec9028b91f8b07b22c5d;>aeaf731 Use @actions/cache version 1.0.6 (https://github-redirect.dependabot.com/actions/cache/issues/525;>#525) https://github.com/actions/cache/commit/56a8a2f77583e58fcda120d0902eccfbc7b220bf;>56a8a2f Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/514;>#514 from eregon/recommend-setup-ruby-bundler-cache https://github.com/actions/cache/commit/1bfe3accb30cbecd1eb79cdba246c3a7fc899cdf;>1bfe3ac Recommend ruby/setup-ruby's bundler-cache: true option https://github.com/actions/cache/commit/354332455a7a9ae5492723ca9d4d082484e173bc;>3543324 Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/434;>#434 from DanielHabenicht/patch-1 https://github.com/actions/cache/commit/3303695afa44b4dd4776286c04fc1fbffe1ae68c;>3303695 Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/507;>#507 from odin-delrio/patch-1 https://github.com/actions/cache/commit/e64ab303d144824d683711d5c78723c915ff952b;>e64ab30 Improved gradle cache key calculation example https://github.com/actions/cache/commit/26c48dce83c8127f120594ca7290654e35acfa03;>26c48dc Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/506;>#506 from actions/cache-matrix-example https://github.com/actions/cache/commit/72f66cfa6dcadd8440e1382d36b556a7a43a52bc;>72f66cf Added a cache example when using matrix https://github.com/actions/cache/commit/9f3a4d3e65eb0e37d28bc055c0d1a91eac6d76fe;>9f3a4d3 Merge pull request https://github-redirect.dependabot.com/actions/cache/issues/443;>#443 from guilleijo/pipenv-example Additional commits viewable in https://github.com/actions/cache/compare/v2...26968a09c0ea4f3e233fdddbafd1166051a095f6;>compare view Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280757#comment-17280757
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 5:31 AM:
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
What I also found out is that the line of code which triggered the
{{ExecutionException}} caught in the last {{catch}} block is the line:
{{clientSocketChannel.connect( hostAddress ).get();}}
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
was (Author: kriegaex):
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
What I also found out is that the line of code which triggered the
{{ExecutionException}} caught in the last {{catch}} block is the line:
{{clientSocketChannel.connect( hostAddress ).get();}}
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
> 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
>Priority: Major
> Attachments: image-2021-02-08-12-07-34-183.png,
> maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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
>
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280757#comment-17280757
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 5:31 AM:
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
What I also found out is that the line of code which triggered the
{{ExecutionException}} caught in the last {{catch}} block is the line:
{{clientSocketChannel.connect( hostAddress ).get();}}
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
was (Author: kriegaex):
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
> 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
>Priority: Major
> Attachments: image-2021-02-08-12-07-34-183.png,
> maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280757#comment-17280757
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
The problem is not the Java agent as such because if you uncomment or delete
those two lines in the {{transform}} method, the test works with the agent:
{code:java}
System.out.println("[Transformer OUT] className = " + className + ",
loader = " + loader);
System.err.println("[Transformer ERR] className = " + className + ",
class file size = " + classfileBuffer.length);
{code}
The problem must be related to something Surefire does with {{System.out}} and
{{System.err}} when using {{SurefireForkNodeFactory}}. Maybe at the moment of
the agent trying to write something to those streams, they somehow are in an
uninitialised state. Maybe you need to guard some parts of the code by a
`synchronized` block or method modifier. Please note that byte code
instrumentation is executed in separate threads at the JVM's discretion. This
can happen at any time a class is being loaded, so you want to make sure to
write thread-safe code in Surefire.
I think this is the best I can do here on my part in order to guide you towards
a solution. But as for your own (project's) code, you certainly know better
where to look for possible problems related to my analysis.
> 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
>Priority: Major
> Attachments: image-2021-02-08-12-07-34-183.png,
> maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280743#comment-17280743
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 5:08 AM:
*Update:* After I noticed that I could reproduce your problem with the broken
log summary on _cmd.exe_, I also tried to reproduce the hang there and now I
also get the dump file with the stack trace you observed, just not in IDEA or
Git Bash. so different consoles seem to make Maven behave differently in both
cases.
*Update 2:* I tried to add log lines to your method where the error occurs in
the hanging build, but the logs beginning with "###" never occur on the console
or in a dump file, as if somehow {{System.out}} is already broken somehow at
the time I want to log.
!image-2021-02-08-12-07-34-183.png!
was (Author: kriegaex):
*Update:* After I noticed that I could reproduce your problem with the broken
log summary on _cmd.exe_, I also tried to reproduce the hang there and now I
also get the dump file with the stack trace you observed, just not in IDEA or
Git Bash. so different consoles seem to make Maven behave differently in both
cases.
> 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
>Priority: Major
> Attachments: image-2021-02-08-12-07-34-183.png,
> maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280739#comment-17280739
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 5:05 AM:
Sorry, yet another new finding: I was talking about the log output produced by
the Java agent when run by Maven. The phenomenon you described
{code:none}
[TraInNsFfOor]m er BEURIRL]D cSlUaCsCsENSaSme
- [jIaNvFaO/u]t
il-/-c-o-n-c-u-r-r-e-n-t-/-E-x-e-c-u-t-o-r-s-$-R-u-n-n-a-b-l-e-A-d-a-p-t-e-r-,-
-c-l-a-s-s- -f-i-l-e- -s-i-z-e- -=- -1-4-3-2-
-
{code}
related to the broken test summary I never saw on the console inside IntelliJ
IDEA or in Git Bash, but now on the regular Windows console (cmd.exe) which I
hardly ever use for builds, but tested just now. It only occurs there and only
on a 3.0 milestone, not in 2.22.2. In Git Bash or IDEA, I only see the problem
reported here, garbled agent output on _stdOut_ vs _stdErr_. So it seems we now
have 3 distinct issues here already. The most pressing one is certainly the
hanging build when using {{SurefireForkNodeFactory}}, but the others should
also be addressed.
The {{- [jIaNvFaO/u]t il-/-c-o-n-c-u-r-r-e-n-t-}} looks like single bytes are
somehow written into a stream or channel by different threads, rather than full
lines which are then flushed.
was (Author: kriegaex):
Sorry, yet another new finding: I was talking about the log output produced by
the Java agent when run by Maven. The phenomenon you described
{code:none}
[TraInNsFfOor]m er BEURIRL]D cSlUaCsCsENSaSme
- [jIaNvFaO/u]t
il-/-c-o-n-c-u-r-r-e-n-t-/-E-x-e-c-u-t-o-r-s-$-R-u-n-n-a-b-l-e-A-d-a-p-t-e-r-,-
-c-l-a-s-s- -f-i-l-e- -s-i-z-e- -=- -1-4-3-2-
-
{code}
related to the broken test summary I never saw on the console inside IntelliJ
IDEA or in Git Bash, but now on the regular Windows console (cmd.exe) which I
hardly ever use for builds, but tested just now. It only occurs there and only
on a 3.0 milestone, not in 2.22.2. In Git Bash or IDEA, I only see the problem
reported here, garbled agent output on _stdOut_ vs _stdErr_. So it seems we now
have 3 distinct issues here already. The most pressing one is certainly the
hanging build when using {{SurefireForkNodeFactory}}, but the others should
also be addressed.
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[GitHub] [maven-invoker-plugin] dependabot[bot] opened a new pull request #34: Bump maven-invoker from 3.0.1 to 3.1.0
dependabot[bot] opened a new pull request #34: URL: https://github.com/apache/maven-invoker-plugin/pull/34 Bumps [maven-invoker](https://github.com/apache/maven-invoker) from 3.0.1 to 3.1.0. Commits https://github.com/apache/maven-invoker/commit/83fdc6a6609806c15e5632ad106119cc13c4674b;>83fdc6a [maven-release-plugin] prepare release maven-invoker-3.1.0 https://github.com/apache/maven-invoker/commit/a16cb71e23fa978531782c5d37e922eda12d2885;>a16cb71 Bump maven-assembly-plugin to 3.3.0 https://github.com/apache/maven-invoker/commit/a83940bf89c5efdba50d00984582451ca144c6d6;>a83940b (doc) javadoc:fix https://github.com/apache/maven-invoker/commit/09cc3c21490262ac8a07e4e8a53f95122eae0140;>09cc3c2 (doc) misc plugin updates https://github.com/apache/maven-invoker/commit/08d0ee13481548485041107748e6cbf6c69ecfa4;>08d0ee1 (doc) Fix compilation issue https://github.com/apache/maven-invoker/commit/b9ea3371ce880db561aff3c30fc9f870b40c8d28;>b9ea337 Workaround for MSHARED-867 - to help CI tools with cleanup https://github.com/apache/maven-invoker/commit/1fbcab6b81178ae9b9afb38e92cc78704f168aae;>1fbcab6 Switch to 3.1.0-SNAPSHOT https://github.com/apache/maven-invoker/commit/bd25b52c9401413d0df66632f0f9b6e8ab259951;>bd25b52 (doc) misc test updates https://github.com/apache/maven-invoker/commit/3f8441fff0229a4feb30d604fcded8e859f3d835;>3f8441f [MSHARED-978] add 'quiet' flag https://github.com/apache/maven-invoker/commit/908ca273f6e3e7cffc4e4109d7e312929173c80b;>908ca27 Misc code cleanup Additional commits viewable in https://github.com/apache/maven-invoker/compare/maven-invoker-3.0.1...maven-invoker-3.1.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280743#comment-17280743
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
*Update:* After I noticed that I could reproduce your problem with the broken
log summary on _cmd.exe_, I also tried to reproduce the hang there and now I
also get the dump file with the stack trace you observed, just not in IDEA or
Git Bash. so different consoles seem to make Maven behave differently in both
cases.
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[GitHub] [maven-dependency-analyzer] dependabot[bot] opened a new pull request #28: Bump maven-invoker from 3.0.1 to 3.1.0
dependabot[bot] opened a new pull request #28: URL: https://github.com/apache/maven-dependency-analyzer/pull/28 Bumps [maven-invoker](https://github.com/apache/maven-invoker) from 3.0.1 to 3.1.0. Commits https://github.com/apache/maven-invoker/commit/83fdc6a6609806c15e5632ad106119cc13c4674b;>83fdc6a [maven-release-plugin] prepare release maven-invoker-3.1.0 https://github.com/apache/maven-invoker/commit/a16cb71e23fa978531782c5d37e922eda12d2885;>a16cb71 Bump maven-assembly-plugin to 3.3.0 https://github.com/apache/maven-invoker/commit/a83940bf89c5efdba50d00984582451ca144c6d6;>a83940b (doc) javadoc:fix https://github.com/apache/maven-invoker/commit/09cc3c21490262ac8a07e4e8a53f95122eae0140;>09cc3c2 (doc) misc plugin updates https://github.com/apache/maven-invoker/commit/08d0ee13481548485041107748e6cbf6c69ecfa4;>08d0ee1 (doc) Fix compilation issue https://github.com/apache/maven-invoker/commit/b9ea3371ce880db561aff3c30fc9f870b40c8d28;>b9ea337 Workaround for MSHARED-867 - to help CI tools with cleanup https://github.com/apache/maven-invoker/commit/1fbcab6b81178ae9b9afb38e92cc78704f168aae;>1fbcab6 Switch to 3.1.0-SNAPSHOT https://github.com/apache/maven-invoker/commit/bd25b52c9401413d0df66632f0f9b6e8ab259951;>bd25b52 (doc) misc test updates https://github.com/apache/maven-invoker/commit/3f8441fff0229a4feb30d604fcded8e859f3d835;>3f8441f [MSHARED-978] add 'quiet' flag https://github.com/apache/maven-invoker/commit/908ca273f6e3e7cffc4e4109d7e312929173c80b;>908ca27 Misc code cleanup Additional commits viewable in https://github.com/apache/maven-invoker/compare/maven-invoker-3.0.1...maven-invoker-3.1.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-dependency-analyzer] dependabot[bot] opened a new pull request #29: Bump asm from 8.0.1 to 9.1
dependabot[bot] opened a new pull request #29: URL: https://github.com/apache/maven-dependency-analyzer/pull/29 Bumps asm from 8.0.1 to 9.1. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-shade-plugin] dependabot[bot] opened a new pull request #84: Bump asmVersion from 9.0 to 9.1
dependabot[bot] opened a new pull request #84: URL: https://github.com/apache/maven-shade-plugin/pull/84 Bumps `asmVersion` from 9.0 to 9.1. Updates `asm` from 9.0 to 9.1 Updates `asm-commons` from 9.0 to 9.1 Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280739#comment-17280739
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
Sorry, yet another new finding: I was talking about the log output produced by
the Java agent when run by Maven. The phenomenon you described
{code:none}
[TraInNsFfOor]m er BEURIRL]D cSlUaCsCsENSaSme
- [jIaNvFaO/u]t
il-/-c-o-n-c-u-r-r-e-n-t-/-E-x-e-c-u-t-o-r-s-$-R-u-n-n-a-b-l-e-A-d-a-p-t-e-r-,-
-c-l-a-s-s- -f-i-l-e- -s-i-z-e- -=- -1-4-3-2-
-
{code}
related to the broken test summary I never saw on the console inside IntelliJ
IDEA or in Git Bash, but now on the regular Windows console (cmd.exe) which I
hardly ever use for builds, but tested just now. It only occurs there and only
on a 3.0 milestone, not in 2.22.2. In Git Bash or IDEA, I only see the problem
reported here, garbled agent output on _stdOut_ vs _stdErr_. So it seems we now
have 3 distinct issues here already. The most pressing one is certainly the
hanging build when using {{SurefireForkNodeFactory}}, but the others should
also be addressed.
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[GitHub] [maven-dependency-plugin] dependabot[bot] opened a new pull request #126: Bump asm from 9.0 to 9.1
dependabot[bot] opened a new pull request #126: URL: https://github.com/apache/maven-dependency-plugin/pull/126 Bumps asm from 9.0 to 9.1. [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280734#comment-17280734
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:56 AM:
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
*Edit:* I verified that in Failsafe 2.22.2 the garbled log output also
occasionally occurs, but it seems to be less frequent. In any case, it is not
directly related to the "hanging build" + fork node issue.
was (Author: kriegaex):
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
> Java agent printing to native console makes build block when using
> SurefireForkNodeFactory
> --
>
> Key: SUREFIRE-1881
> URL:
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280736#comment-17280736
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:53 AM:
Here is a Maven log file for the hanging build situation with debug logging
activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit4\3.0.0-M5\common-junit4-3.0.0-M5.jar
[DEBUG] boot(compact) classpath: surefire-booter-3.0.0-M5.jar
surefire-api-3.0.0-M5.jar surefire-logger-api-3.0.0-M5.jar
surefire-shared-utils-3.0.0-M4.jar surefire-extensions-spi-3.0.0-M5.jar
test-classes surefire-print-console-problems-1.0-SNAPSHOT.jar
junit-4.13.1.jar hamcrest-core-1.3.jar surefire-junit4-3.0.0-M5.jar
common-java5-3.0.0-M5.jar common-junit3-3.0.0-M5.jar
common-junit4-3.0.0-M5.jar
[DEBUG] Forking command line: cmd.exe /X /C ""C:\Program
Files\Java\jdk-15.0.2\bin\java"
-javaagent:C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
-jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876\surefirebooter561074834657146383.jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876
2021-02-08T10-38-32_566-jvmRun1 surefire10506462700469984517tmp
surefire_014028304743446008368tmp"
{code}
[^maven-failsafe-debug-log.txt]
was (Author: kriegaex):
Here is a Maven log file for the hanging build situationwith debug logging
activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280736#comment-17280736
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:53 AM:
Here is a Maven log file for the hanging build situationwith debug logging
activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit4\3.0.0-M5\common-junit4-3.0.0-M5.jar
[DEBUG] boot(compact) classpath: surefire-booter-3.0.0-M5.jar
surefire-api-3.0.0-M5.jar surefire-logger-api-3.0.0-M5.jar
surefire-shared-utils-3.0.0-M4.jar surefire-extensions-spi-3.0.0-M5.jar
test-classes surefire-print-console-problems-1.0-SNAPSHOT.jar
junit-4.13.1.jar hamcrest-core-1.3.jar surefire-junit4-3.0.0-M5.jar
common-java5-3.0.0-M5.jar common-junit3-3.0.0-M5.jar
common-junit4-3.0.0-M5.jar
[DEBUG] Forking command line: cmd.exe /X /C ""C:\Program
Files\Java\jdk-15.0.2\bin\java"
-javaagent:C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
-jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876\surefirebooter561074834657146383.jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876
2021-02-08T10-38-32_566-jvmRun1 surefire10506462700469984517tmp
surefire_014028304743446008368tmp"
{code}
[^maven-failsafe-debug-log.txt]
was (Author: kriegaex):
Here is a Maven log file I with debug logging activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280734#comment-17280734
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:45 AM:
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
was (Author: kriegaex):
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
Edit: Here is a Maven log file I with debug logging activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280736#comment-17280736
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
[^maven-failsafe-debug-log.txt]
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280736#comment-17280736
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:45 AM:
Here is a Maven log file I with debug logging activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit4\3.0.0-M5\common-junit4-3.0.0-M5.jar
[DEBUG] boot(compact) classpath: surefire-booter-3.0.0-M5.jar
surefire-api-3.0.0-M5.jar surefire-logger-api-3.0.0-M5.jar
surefire-shared-utils-3.0.0-M4.jar surefire-extensions-spi-3.0.0-M5.jar
test-classes surefire-print-console-problems-1.0-SNAPSHOT.jar
junit-4.13.1.jar hamcrest-core-1.3.jar surefire-junit4-3.0.0-M5.jar
common-java5-3.0.0-M5.jar common-junit3-3.0.0-M5.jar
common-junit4-3.0.0-M5.jar
[DEBUG] Forking command line: cmd.exe /X /C ""C:\Program
Files\Java\jdk-15.0.2\bin\java"
-javaagent:C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
-jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876\surefirebooter561074834657146383.jar
C:\Users\alexa\AppData\Local\Temp\surefire9451725175277362876
2021-02-08T10-38-32_566-jvmRun1 surefire10506462700469984517tmp
surefire_014028304743446008368tmp"
{code}
[^maven-failsafe-debug-log.txt]
was (Author: kriegaex):
[^maven-failsafe-debug-log.txt]
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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
[jira] [Updated] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Kriegisch updated SUREFIRE-1881:
--
Attachment: maven-failsafe-debug-log.txt
> 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
>Priority: Major
> Attachments: maven-failsafe-debug-log.txt
>
>
> 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
> {{ 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)
[jira] [Comment Edited] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280734#comment-17280734
]
Alexander Kriegisch edited comment on SUREFIRE-1881 at 2/8/21, 3:44 AM:
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
Edit: Here is a Maven log file I with debug logging activated (see attachment)
{code:none}
[INFO] ---
[INFO] T E S T S
[INFO] ---
[DEBUG] Determined Maven Process ID 12664
[DEBUG] Fork Channel [1] connection string 'tcp://192.168.137.1:56560' for the
implementation class
org.apache.maven.plugin.surefire.extensions.SurefireForkChannel
[DEBUG] boot classpath:
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-booter\3.0.0-M5\surefire-booter-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-api\3.0.0-M5\surefire-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-logger-api\3.0.0-M5\surefire-logger-api-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-shared-utils\3.0.0-M4\surefire-shared-utils-3.0.0-M4.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-extensions-spi\3.0.0-M5\surefire-extensions-spi-3.0.0-M5.jar
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\test-classes
C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target\surefire-print-console-problems-1.0-SNAPSHOT.jar
C:\Users\alexa\.m2\repository\junit\junit\4.13.1\junit-4.13.1.jar
C:\Users\alexa\.m2\repository\org\hamcrest\hamcrest-core\1.3\hamcrest-core-1.3.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\surefire-junit4\3.0.0-M5\surefire-junit4-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-java5\3.0.0-M5\common-java5-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit3\3.0.0-M5\common-junit3-3.0.0-M5.jar
C:\Users\alexa\.m2\repository\org\apache\maven\surefire\common-junit4\3.0.0-M5\common-junit4-3.0.0-M5.jar
[DEBUG] boot(compact) classpath: surefire-booter-3.0.0-M5.jar
surefire-api-3.0.0-M5.jar surefire-logger-api-3.0.0-M5.jar
surefire-shared-utils-3.0.0-M4.jar surefire-extensions-spi-3.0.0-M5.jar
test-classes surefire-print-console-problems-1.0-SNAPSHOT.jar
junit-4.13.1.jar hamcrest-core-1.3.jar surefire-junit4-3.0.0-M5.jar
common-java5-3.0.0-M5.jar common-junit3-3.0.0-M5.jar
common-junit4-3.0.0-M5.jar
[DEBUG] Forking command line: cmd.exe /X /C ""C:\Program
Files\Java\jdk-15.0.2\bin\java"
-javaagent:C:\Users\alexa\Documents\java-src\Maven_Surefire_PrintToConsoleProblems\target/surefire-print-console-problems-1.0-SNAPSHOT.jar
-jar
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280734#comment-17280734
]
Alexander Kriegisch commented on SUREFIRE-1881:
---
Sorry for the late answer, but we are in different time zones.
bq. I have observed exactly the same screen as you had (printed T E S T S and
then nothing). The dump file exists with the exception in it.
Well, I also use Win10. I tried with Java 14 first, then in order to match your
setup installed JDK 15 (without much hope), and again I cannot reproduce the
dump. The {{target/failsafe-reports}} directory does not even get created when
the configuration makes the integration test hang during {{mvn clean verify}}.
Do you have any idea how I could reproduce this in order to get the dump file?
Or do you maybe simply have a Windows firewall problem, not having given Java
full network access rights?
bq. After the forkNode is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
Well, I hoped you could tell me. I reported the same two problems, hoping that
a Surefire maintainer could find their root causes and fix them.
The garbled log output seems to be even worse on your system than on mine. One
observation I just made is that the garbled log output occurs when the agent
writes to *both* native _stdErr_ and _stdOut_, mixing both on the console as
seen by the user. When commenting out statements involving {{System.err}} or
{{System.out}} and only printing to one channel, the problems disappear.
Probably the console resource is not synchronised and/or e.g. _stdOut_ flushes
after each println, _stdErr_ does not. But that is just speculation. I do
remember this kind of messed up console logs from other Java tests running in
Maven too when writing mixed output to both channels, e.g. when normal logging
goes to _stdOut_ and stack traces go to _stdErr_. So that might be a
manifestation of a more general problem. I do think that it is Maven-specific,
because when I run the same integration test from IntelliJ IDEA, the log output
is as expected. Hence, I would assume that somewhere in a Maven or Surefire
component there is a lack of synchronisation with regard to resource access.
> 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
>Priority: Major
>
> 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
> {{ 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)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280710#comment-17280710
]
Tibor Digana commented on MNG-7052:
---
I have expected from the design of the pattern {{a-zA-Z0-9-_}} in profile that
the CLI interference was considered. Obviosly it wasn't and it has to be
changed. Somebody may want to have an expression in the profile name (or
characters like '+', '.', '=') and this pattern would become a blocker, and the
future may bring any requirements from the users.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280705#comment-17280705
]
Tibor Digana commented on MNG-7052:
---
I do not like any unique pattern. Every ID has own meaning and purpose.
Different of course, and so the pattern cannot be unique.
In this case the profile name may have own pattern. You can see that the
pattern {{a-zA-Z0-9-_}} broke the backwards compatibility. The first character
can have a special treatment and it does not mean that we have to impose such
strict restrictions. All can be ensured properly without breaking backwards
compatibility.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280683#comment-17280683 ] Michael Osipov commented on MNG-6795: - [~tcrawley], headers denote metadata, not messages. Using a header seems wrong to me. I was thinking about using RFC 7807, but frankly Wagon cannot and will not make any assumptions about the target endpoint. So, without knowing the actual context Wagon is running in it is virtually impossible to do so. Also note that Wagon is generic transport, not related to Maven repositories at all. Another problem is that Wagon is protocol agnostic, this means that even if we add those information to Wagon exceptions, it remains unused for ther Wagon implementations except HTTP. WDYT? > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280678#comment-17280678
]
Michael Osipov commented on MNG-7052:
-
Items in question:
{noformat}
osipovmi@deblndw011x:~/var/Projekte/maven (revert-MNG-6772=)
$ grep -n '>id<' ./maven-settings/src/main/mdo/settings.mdo
./maven-model/src/main/mdo/maven.mdo
# IdentifiableBase: Mirror, Profile, Proxy, Server
./maven-settings/src/main/mdo/settings.mdo:97: id
# RepositoryBase: Repository
./maven-settings/src/main/mdo/settings.mdo:813: id
# Developer
./maven-model/src/main/mdo/maven.mdo:1176: id
# RepositoryBase: Repository
./maven-model/src/main/mdo/maven.mdo:1869: id
# Site
./maven-model/src/main/mdo/maven.mdo:2037: id
# PluginExecution
./maven-model/src/main/mdo/maven.mdo:2381: id
# Profile
./maven-model/src/main/mdo/maven.mdo:2561: id
# ReportSet
./maven-model/src/main/mdo/maven.mdo:2921: id
{noformat}
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280667#comment-17280667
]
Michael Osipov commented on MNG-7052:
-
Regardless of the actual characters, we need to cover more spots:
* We need to decide whether we want to treat item ids just like we treat
groupId/artifactId on terms of validation
* Only profile ids are covers, what about repo ids and other ids on the POM?
* The settings model does not validation which allows to create items which
would not pass validation inside a POM
I propose to create a ticket to:
* Collect all affected id items
* Discuss the first point of the list
* settle on a set of chars which does not interfere with: CLI args/options,
shell interpolation, maven interpolation
Does this sound acceptable?
Note: A profile id cannot start with a plus char because it has a specific
internal meaning.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280659#comment-17280659
]
Tibor Digana commented on MNG-7052:
---
[~mthmulders]
I guess we are intelligent people and we do not imply restrictions where not
neessary!
Why such regex? We are talking about the plus at the position zero:
{{else if ( token.charAt( 0 ) == '+' )}}
There is no reason to be restrictive at every position...
We are able to imply restrictions at the first character other than elsewhere.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280650#comment-17280650
]
Maarten Mulders edited comment on MNG-7052 at 2/7/21, 8:25 PM:
---
Although it was never documented, the plus character also allowed to *select* a
profile (see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {{+}} character, as it might be confusing.
was (Author: mthmulders):
Although it was never documented, the {{+}} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {{+}} character, as it might be confusing.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280650#comment-17280650
]
Maarten Mulders edited comment on MNG-7052 at 2/7/21, 8:24 PM:
---
Although it was never documented, the {{+}} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {{+}} character, as it might be confusing.
was (Author: mthmulders):
Although it was never documented, the {+} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {+} character, as it might be confusing.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280650#comment-17280650
]
Maarten Mulders commented on MNG-7052:
--
Although it was never documented, the {{+}} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {{+}} character, as it might be confused.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280650#comment-17280650
]
Maarten Mulders edited comment on MNG-7052 at 2/7/21, 8:23 PM:
---
Although it was never documented, the {+} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {+} character, as it might be confusing.
was (Author: mthmulders):
Although it was never documented, the {{+}} also allowed to *select* a profile
(see [this discussion on the merge
request|https://github.com/apache/maven/pull/429#discussion_r563383850]). So I
don't think we could allow the {{+}} character, as it might be confused.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280647#comment-17280647
]
Martin Kanters commented on MNG-7052:
-
[~tibordigana] This decision was taken together with [~rfscholte] and
[~mthmulders] almost two months ago I believe, so my memory might be a bit
foggy. As far as I remember IDs in the POM are usually checked against the
regex shown in the issue description, but the profile ID was never checked.
This needed to be made consistent. I don't necessarily think the + sign should
be a problem, as long as it is not the first characters. ('+' is currently the
opposite character from the '-' character, which can be used to unselect
profiles or projects).
Personally I don't know whether the + can or should be added to the list.
Perhaps Robert or Michael can give their take on this. I'm not sure what the
impact could be.
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana edited comment on MNG-7052 at 2/7/21, 8:02 PM:
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character + is not
in this regex. I have reasonable name of the profile {{jdk9+}} which works fine
with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
was (Author: tibor17):
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character "+" is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana edited comment on MNG-7052 at 2/7/21, 8:01 PM:
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character "+" is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
was (Author: tibor17):
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character '+' is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana edited comment on MNG-7052 at 2/7/21, 8:01 PM:
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character plus is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
was (Author: tibor17):
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character '+' is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana edited comment on MNG-7052 at 2/7/21, 8:01 PM:
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character '+' is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
was (Author: tibor17):
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character plus is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana edited comment on MNG-7052 at 2/7/21, 8:00 PM:
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character '+' is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
was (Author: tibor17):
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character {{+}} is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-7052) Do not allow symbols as first character of identifiers in the POM
[
https://issues.apache.org/jira/browse/MNG-7052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280645#comment-17280645
]
Tibor Digana commented on MNG-7052:
---
[~martinkanters]
Having 4.0.0 in comparison with 3.6.x the customer build becomes broken, see
[this|https://github.com/apache/maven-surefire/pull/334]. I do not mind about
the first character if the limitation is there but it is bad if all characters
have such a restriction {{a-zA-Z0-9-_}} and for instance the character {{+}} is
not in this regex. I have reasonable name of the profile {{jdk9+}} which works
fine with 3.6.3 but I cannot use it in 4.0.0. So I would allow *all* ASCII
characters (except control chars and non visible chars). Do you see having plus
'+' as a conflict with some Maven expressions? Why it was not included in the
default pattern already in 4.0.0?
> Do not allow symbols as first character of identifiers in the POM
> -
>
> Key: MNG-7052
> URL: https://issues.apache.org/jira/browse/MNG-7052
> Project: Maven
> Issue Type: Improvement
> Components: core
>Reporter: Martin Kanters
>Priority: Major
> Labels: up-for-grabs
> Fix For: 4.0.x-candidate
>
>
> In the {{DefaultModelValidator}} we currently validate identifiers against
> {{a-zA-Z0-9-_.}}
> Since Maven also allows operators to be used against an identifier, this can
> result in bugs or at least unexpected behavior for the user.
> The minus operator can be used to deactivate a certain profile, so an example
> would be:
> - A project having a profile with the id {{-id-of-profile}}
> - A Maven invocation of {{mvn -P-id-of-profile}}.
> The release of Maven 4 is a nice opportunity to restrict the first character
> of an id to be {{a-zA-Z0-9}} . The other characters may still consist of
> those symbols.
> This should apply to all identifiers that we support. The methods that need
> attention are:
> {{DefaultModelValidator#validateId}} and
> {{DefaultModelValidator#validateIdWithWildcards}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] mthmulders commented on pull request #334: Fix build error with latest Maven 4.0 snapshot
mthmulders commented on pull request #334: URL: https://github.com/apache/maven-surefire/pull/334#issuecomment-774744989 > @Tibor17 I think it's caused by this commit: [apache/maven@8defd16#diff-690df442061d3325c6a7cf7b687e90ae79dd3639d45b8d1e606ad1bbc97a00e2](https://github.com/apache/maven/commit/8defd169651db30fe0ac3ad3f318e471f0241d02#diff-690df442061d3325c6a7cf7b687e90ae79dd3639d45b8d1e606ad1bbc97a00e2) That is correct, the changes relate to [MNG-7051](https://issues.apache.org/jira/browse/MNG-7051). This ticket says: > Note that this breaks the current behaviour of Maven 3 in two ways: > 1. `-P apache-release` will currently log a warning and not break the build. That behaviour can be restored by adding the ?. > 1. A profile that has an identifier that not valid (i.e., contains anything else than `a - z`, `A - Z`, `0 - 9`, `-`, `_` or `.`) will break the build. More information is also in this other ticket: [MNG-7052](https://issues.apache.org/jira/browse/MNG-7052). 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] marcphilipp commented on pull request #334: Fix build error with latest Maven 4.0 snapshot
marcphilipp commented on pull request #334: URL: https://github.com/apache/maven-surefire/pull/334#issuecomment-774730627 @Tibor17 I think it's caused by this commit: https://github.com/apache/maven/commit/8defd169651db30fe0ac3ad3f318e471f0241d02#diff-690df442061d3325c6a7cf7b687e90ae79dd3639d45b8d1e606ad1bbc97a00e2 The allowed characters are defined here: https://github.com/apache/maven/blob/8defd169651db30fe0ac3ad3f318e471f0241d02/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L878-L881 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 edited a comment on pull request #334: Fix build error with latest Maven 4.0 snapshot
Tibor17 edited a comment on pull request #334: URL: https://github.com/apache/maven-surefire/pull/334#issuecomment-774729429 It looks like something has changed in Maven. Was it reasonable change or it is a bug in Maven. I checked Maven 3.6.3 and it worked fine. So i guess we should start with asking the colleagues about the pattern and collision characters with some expressions. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] Tibor17 commented on pull request #334: Fix build error with latest Maven 4.0 snapshot
Tibor17 commented on pull request #334: URL: https://github.com/apache/maven-surefire/pull/334#issuecomment-774729429 It looks like something has changed in Maven. Was it reasonable change or it is a bug in Maven. I checked Maven 3.6.3 and it work fine. So i guess we should start with asking the colleagues about the pattern and collision characters with some expressions. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280595#comment-17280595 ] Tobias Crawley edited comment on MNG-6795 at 2/7/21, 3:50 PM: -- I am one of the maintainers of [clojars.org|https://clojars.org], a repository of OSS libraries for the Clojure community. We currently use ReasonPhrase to return additional context with failed deployments that are intended to be read by the user and not parsed programmatically. We currently use [a deprecated method in Jetty|https://www.eclipse.org/jetty/javadoc/jetty-11/org/eclipse/jetty/server/Response.html#setStatus(int,java.lang.String)] to set it. I would much prefer another way to provide this context; a header that is treated as a plaintext string and displayed by the wagon in place of ReasonPhrase would work well for us. was (Author: tcrawley): I am one of the maintainers of clojars.org, a repository of OSS libraries for the Clojure community. We currently use ReasonPhrase to return additional context with failed deployments that are intended to be read by the user and not parsed programmatically. We currently use [a deprecated method in Jetty|https://www.eclipse.org/jetty/javadoc/jetty-11/org/eclipse/jetty/server/Response.html#setStatus(int,java.lang.String)] to set it. I would much prefer another way to provide this context; a header that is treated as a plaintext string and displayed by the wagon in place of ReasonPhrase would work well for us. > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6795) define a replacement for ReasonPhrase to display details about transfert failures
[ https://issues.apache.org/jira/browse/MNG-6795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280595#comment-17280595 ] Tobias Crawley commented on MNG-6795: - I am one of the maintainers of clojars.org, a repository of OSS libraries for the Clojure community. We currently use ReasonPhrase to return additional context with failed deployments that are intended to be read by the user and not parsed programmatically. We currently use [a deprecated method in Jetty|https://www.eclipse.org/jetty/javadoc/jetty-11/org/eclipse/jetty/server/Response.html#setStatus(int,java.lang.String)] to set it. I would much prefer another way to provide this context; a header that is treated as a plaintext string and displayed by the wagon in place of ReasonPhrase would work well for us. > define a replacement for ReasonPhrase to display details about transfert > failures > - > > Key: MNG-6795 > URL: https://issues.apache.org/jira/browse/MNG-6795 > Project: Maven > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 3.3.9, 3.6.3 >Reporter: Herve Boutemy >Priority: Major > Fix For: 4.0.x-candidate > > > as documented in WAGON-541 > [372aa52c80c2f7b458c095d837e15ebeafbdf0b7|https://gitbox.apache.org/repos/asf?p=maven-wagon.git=commit=372aa52c80c2f7b458c095d837e15ebeafbdf0b7], > ReasonPhrase has been removed from HTTP/2 and deprecated (optional) in > HTTP/1.1 for more than five years. It is useful to give detailed error > messages on artifact transfert errors with a repository manager. > A replacement has to be found -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-7049) Version range resolution downloads all poms, not just the highest version
[ https://issues.apache.org/jira/browse/MNG-7049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280488#comment-17280488 ] Moti Nisenson-Ken commented on MNG-7049: [~elismaga] - not really - we worked around by explicitly managing the lower bound of the range so that the range wouldn't contain any bad poms. This doesn't help with the fact that it still downloads and resolves all the poms, and it also meant needing to maintain something additional. > Version range resolution downloads all poms, not just the highest version > - > > Key: MNG-7049 > URL: https://issues.apache.org/jira/browse/MNG-7049 > Project: Maven > Issue Type: Improvement > Components: core >Reporter: Moti Nisenson-Ken >Priority: Major > > When specifying a version range for a dependency, maven will download and try > to resolve all poms in that range which satisfy the range. The usage however > is only to use the highestVersion. This causes two issues: > # Performance - it's downloading numerous poms that aren't needed. > # Fragility - if the version range covers any "bad" poms, then the build > will fail. For example, consider that for a specific version, the parent of a > pom is not present in the repository. This is enough to fail any build with a > version range covering that specific version, as the range resolution stage > will not complete. This is particularly harmful when that version would not > be selected as the highest, anyway. > Recommend to have a system property to control the desired behavior - it > should be possible to short-circuit loading all the versions and to just to > load the highest version. > For another user report of this see: > [https://stackoverflow.com/questions/25047859/restrict-maven-to-not-download-all-poms] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1881) Java agent printing to native console makes build block when using SurefireForkNodeFactory
[
https://issues.apache.org/jira/browse/SUREFIRE-1881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17280470#comment-17280470
]
Tibor Digana commented on SUREFIRE-1881:
It was observed from Windows 10.
I am using this line {{}}
and I have observed exactly the same screen as you had (printed *T E S T S*
and then nothing). The dump file exists with the exception in it.
After the {{forkNode}} is deleted the test runs but strange and broken test
summary is printed which cannot be normally read. How this can be explained?
{noformat}
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.378 s
- in de.scrum_master.dummy.AgentIT
[Transformer OUT] className = org/junit/runner/notification/RunNotifier$2,
loader = jdk.internal.loader.ClassLoaders$AppClassLoader@6ff3c5b5
[Transformer ERR] className = org/junit/runner/notification/RunNotifier$2,
class file size = 1131
[Transformer OUT] className = org/apache/maven/surefire/api/suite/RunResult,
loader = jdk.internal.loader.ClassLoaders$AppClassLoader@6ff3c5b5
[Transformer ERR] className = org/apache/maven/surefire/api/suite/RunResult,
class file size = 5263
[Transformer OUT] className = org/apache/maven/surefire/booter/ForkedBooter$6,
loader = jdk.internal.loader.ClassLoaders$AppClassLoader@6ff3c5b5
[Transformer ERR] className = org/apache/maven/surefire/booter/ForkedBooter$6,
class file size = 1036
[Transformer OUT] className = org/apache/maven/surefire/booter/ForkedBooter$7,
loader = jdk.internal.loader.ClassLoaders$AppClassLoader@6ff3c5b5
[Transformer ERR] className = org/apache/maven/surefire/booter/ForkedBooter$7,
class file size = 1564
[Transformer OUT] className =
java/util/concurrent/ScheduledThreadPoolExecutor$ScheduledFutureTask, loader =
null
Transformer ERR] className =
java/util/concurrent/ScheduledThreadPoolExecutor$ScheduledFutureTask, class
file size =[ 4I3NF3O8]
[INFO] Results:
[Transformer OUT] className = java/util/concurrent/FutureTask, loader = null
m[TrINaFnOsf]o r
ir[ ERIRN]F Ocl]a ssNTaemset s= rjuanv:a /1u,t iFla/iclounrceusr:r e0n,t
/EFrurtourrse:T a0s,k ,S kcilpapseds: 0 f
[eI NsFiOze] =
9022
[WARNING] Corrupted STDOUT by directly writing to native stream in forked JVM
1. See FAQ web page and the dump file
c:\vcs\github\Maven_Surefire_PrintToConsoleProblems\target\failsafe-reports\2021-02-06T20-17-54_730-jvmRun1.dumpstream
[Transformer OUT] className = java/util/concurrent/FutureTask$WaitNode, loader
= null
-Transformer ERR] className = java/util/concurrent/FutureTask$WaitNo[de,I
NcFlOas]s f-i-l-e- -s-i-z-e- -=- -5-5-4-
[Transformer OUT] className = java/util/concurrent/Executors$RunnableAdapter,
loader = null
[TraInNsFfOor]m er BEURIRL]D cSlUaCsCsENSaSme
- [jIaNvFaO/u]t
il-/-c-o-n-c-u-r-r-e-n-t-/-E-x-e-c-u-t-o-r-s-$-R-u-n-n-a-b-l-e-A-d-a-p-t-e-r-,-
-c-l-a-s-s- -f-i-l-e- -s-i-z-e- -=- -1-4-3-2-
-
[Transformer OUT] className = java/util/concurrent/ThreadPoolExecutor$Worker,
loader = null
v[TranIsNfFoOrm] Terot ERaRl] t icmlea:s s N1a1m.e2 0=1 jsa
s/u[tiIlN/FcOon]c uFrirneinsth/eTdh raeta:d
P2o0o2l1E-x0e2c-u0t6orT20$:W1o8r:k0e0r+,0 1c:l0a0s
-[filIeN FsOiz]e =- -2-3-9-7-
-
[Transformer OUT] className =
java/util/concurrent/locks/AbstractQueuedSynchronizer$SharedNode, load
{noformat}
> 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
>Priority: Major
>
> 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
> {{ 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]
>
