[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17386942#comment-17386942
 ] 

Guy Brand commented on MNG-7161:


[~michael-o] I think this should be MNG-7196 correct? Thanks for fixing this! 

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Critical
> Fix For: 3.8.2, 4.0.0, 4.0.0-alpha-1
>
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> Maven 4.0.0. This would also make this part future proof, as when there are 
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets 

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376533#comment-17376533
 ] 

Guy Brand commented on MNG-7161:


Also see [https://github.com/fusesource/jansi/issues/214] which is the issue 
reported at Jansi to fix the root cause.

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> Maven 4.0.0. This would also make this part future proof, as when there are 
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that 

[jira] [Commented] (MSHARED-993) Make MessageUtils resilient to failures during uninstall

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHARED-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376518#comment-17376518
 ] 

Guy Brand commented on MSHARED-993:
---

The respective pull request https://github.com/apache/maven-shared-utils/pull/93

> Make MessageUtils resilient to failures during uninstall
> 
>
> Key: MSHARED-993
> URL: https://issues.apache.org/jira/browse/MSHARED-993
> Project: Maven Shared Components
>  Issue Type: Improvement
>Affects Versions: maven-shared-utils-3.3.4
>Reporter: Guy Brand
>Priority: Critical
>
> Out of https://issues.apache.org/jira/browse/MNG-7161 it was proposed to make 
> [this part 
> |https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L97-L103]where
>  the {{AnsiConsole}} gets uninstalled resilient when errors occur. This kind 
> of error handling has already been done 
> [here|https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for the shutdown hook.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17376519#comment-17376519
 ] 

Guy Brand commented on MNG-7161:


I've opened https://issues.apache.org/jira/browse/MSHARED-993 and the 
[respective pull request|https://github.com/apache/maven-shared-utils/pull/93]. 
[~michael-o] Is there something missing and can you take it from here to push a 
new release of the Maven shared utils library and update it accordingly on 
{{master}} ?

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> 

[jira] [Created] (MSHARED-993) Make MessageUtils resilient to failures during uninstall

[Guy Brand (Jira)]

Guy Brand created MSHARED-993:
-

 Summary: Make MessageUtils resilient to failures during uninstall
 Key: MSHARED-993
 URL: https://issues.apache.org/jira/browse/MSHARED-993
 Project: Maven Shared Components
  Issue Type: Improvement
Affects Versions: maven-shared-utils-3.3.4
Reporter: Guy Brand


Out of https://issues.apache.org/jira/browse/MNG-7161 it was proposed to make 
[this part 
|https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L97-L103]where
 the {{AnsiConsole}} gets uninstalled resilient when errors occur. This kind of 
error handling has already been done 
[here|https://github.com/apache/maven-shared-utils/blob/9f40037bfb04d54dd997a9ab837390045c9a4348/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
 for the shutdown hook.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17374662#comment-17374662
 ] 

Guy Brand commented on MNG-7161:


[~michael-o] Yes I'll try to have something ready by the end of this week. 

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.8.2, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
> Fix For: 4.0.x-candidate, 3.8.x-candidate
>
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> Maven 4.0.0. This would also make this part future proof, as when there are 
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report this to JAnsi too such that this gets fixed there as 
> well.
>  
> What 

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361527#comment-17361527
 ] 

Guy Brand commented on MNG-7161:


[~michael-o] [~gnodet] Are you ok with doing the proposed option #2 ? We are 
currently not able to reliably test with the latest Maven nightly, therefore 
should we provide a pull request for that change such that we can get that into 
the main branch soonish?

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.x-candidate, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> Maven 4.0.0. This would also make this part future proof, as when there are 
> other errors thrown during the 

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17351985#comment-17351985
 ] 

Guy Brand commented on MNG-7161:


[~mthmulders] the Maven Archetype plugin also uses the Plexus interactivity: 
[https://github.com/apache/maven-archetype/blob/master/pom.xml#L163-L173] So it 
might be the same issue as we face.

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.x-candidate, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other extensions/plugin out there which also retrieve a 
> reference for the system output streams and therefore they would fail with 
> Maven 4.0.0. This would also make this part future proof, as when there are 
> other errors thrown during the uninstall, Maven itself does not break.
> We can as well report 

[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17351778#comment-17351778
 ] 

Guy Brand commented on MNG-7161:


[~michael-o] We use it for the included {{Prompter}} but we'll now remove this 
dependency and do it by our own to fix this for the current extension. But we'd 
like that all our old extensions still work with Maven 4.0.0 and this error 
would not make it possible.

This error can always occur when a plugin or extension holds a reference to the 
system output streams and then does it's own disposal or similar before JAnsi 
uninstalls itself.

[~mthmulders] Thanks for adding another example.

> Error thrown during uninstalling of JAnsi
> -
>
> Key: MNG-7161
> URL: https://issues.apache.org/jira/browse/MNG-7161
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 4.0.x-candidate, 4.0.0, 4.0.0-alpha-1
>Reporter: Guy Brand
>Priority: Critical
>
> Our integration tests stopped working after we started to test with a Maven 
> {{4.0.0-alpha-1}} nightly which included this commit: 
> [https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]
> In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
> being upgraded. When we then run our integration tests we get the following 
> null pointer exception:
> {code:java}
> java.lang.NullPointerException
>   at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
>   at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
>   at 
> org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
>   at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
>   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
> Method)
>   at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
>   at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
>   at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
> {code}
>  
>  We debugged this and [these 
> changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
>  in JAnsi introduced in the above upgraded version, is the source of the 
> exception. The NPE is caused because the {{out}} reference is {{null}} at the 
> time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
> because we use the Plexus interactivity library which [disposes the 
> {{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
>  on the tear down of Plexus, in which the {{System.out}} reference will be 
> closed which is in fact the {{out}} reference of the {{AnsiConsole}} JAnsi 
> will be [initialized 
> before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
>  the Plexus container). This happens 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
>  so before JAnsi will be uninstalled in 
> [here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].
> There are two options to solve this:
>  1. Report this to JAnsi such that they catch this valid use case and do not 
> throw as this worked without any exceptions in older versions.
>  2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
> swallow them, as if it can't uninstall it, then Maven itself is not capable 
> of fixing this state either. This is already done in a similar way 
> [here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
>  for removing the shutdown hook.
> Our proposal is to do #2 which would make Maven itself resilient to such use 
> cases as there are other 

[jira] [Created] (MNG-7161) Error thrown during uninstalling of JAnsi

[Guy Brand (Jira)]

Guy Brand created MNG-7161:
--

 Summary: Error thrown during uninstalling of JAnsi
 Key: MNG-7161
 URL: https://issues.apache.org/jira/browse/MNG-7161
 Project: Maven
  Issue Type: Bug
Affects Versions: 4.0.x-candidate, 4.0.0, 4.0.0-alpha-1
Reporter: Guy Brand


Our integration tests stopped working after we started to test with a Maven 
{{4.0.0-alpha-1}} nightly which included this commit: 
[https://github.com/apache/maven/commit/195fb626a9a4e5a0774f779b6d8da1cb9ef38468#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8R310-R317]

In this commit the {{maven-shared-utils}} and the {{jansi}} dependencies are 
being upgraded. When we then run our integration tests we get the following 
null pointer exception:
{code:java}
java.lang.NullPointerException
  at org.fusesource.jansi.AnsiPrintStream.uninstall(AnsiPrintStream.java:79)
  at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
  at 
org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
  at 
org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:203)
  at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
  at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
  at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  at java.base/java.lang.reflect.Method.invoke(Method.java:566)
  at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
  at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
{code}
 
 We debugged this and [these 
changes|https://github.com/fusesource/jansi/commit/63bd892b2bdfc253ec119a57bdd42df5e80fd859#diff-d59db8655d9ae2d11948e2b411c34fc9e8513f29065d82c978d7128dafbe3bafR414-R420]
 in JAnsi introduced in the above upgraded version, is the source of the 
exception. The NPE is caused because the {{out}} reference is {{null}} at the 
time it wants to uninstall the {{AnsiOutputStream}}. This reference is nulled 
because we use the Plexus interactivity library which [disposes the 
{{DefaultOutputHandler}}|https://github.com/codehaus-plexus/plexus-interactivity/blob/master/plexus-interactivity-api/src/main/java/org/codehaus/plexus/components/interactivity/DefaultOutputHandler.java#L51-L54]
 on the tear down of Plexus, in which the {{System.out}} reference will be 
closed which is in fact the {{out}} reference of the {{AnsiConsole (}}JAnsi 
will be[ initialized 
before|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L200]
 the Plexus container). This happens 
[here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L202],
 so before JAnsi will be uninstalled in 
[here|https://github.com/apache/maven/blob/3e917677e484067b853eaa4a6de44ebcf5a988de/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L203].

There are two options to solve this:
 1. Report this to JAnsi such that they catch this valid use case and do not 
throw as this worked without any exceptions in older versions.
 2. Fix the {{MessageUtils#doSystemUninstall()}} and catch all exceptions and 
swallow them, as if it can't uninstall it, then Maven itself is not capable of 
fixing this state either. This is already done in a similar way 
[here|https://github.com/apache/maven-shared-utils/blob/17091d82508deb9b7067f3434ba16f660ffc5023/src/main/java/org/apache/maven/shared/utils/logging/MessageUtils.java#L85-L92]
 for removing the shutdown hook.

Our proposal is to do #2 which would make Maven itself resilient to such use 
cases as there are other extensions/plugin out there which also retrieve a 
reference for the system output streams and therefore they would fail with 
Maven 4.0.0. This would also make this part future proof, as when there are 
other errors thrown during the uninstall, Maven itself does not break.

We can as well report this to JAnsi too such that this gets fixed there as well.

 

What are your opinions on that?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339421#comment-17339421
 ] 

Guy Brand commented on MRESOLVER-153:
-

Ok, but then you can use this IT to reproduce it when you add a specific amount 
of retry to the test. I'm just saying that using what we have as performance 
test is not correct, as the results are not comparable at all and don't fulfill 
the requirements for a proper performance test. Therefore doing future tests 
with our setup to test performance makes no sense IMO. I assume these are the 
kind of tests which you meant above in _ Would be available to perform some 
additional tests?_ correct?

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339060#comment-17339060
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] I did some runs with 4 and 8 but I can't identify a huge 
improvement as we use a local proxy that caches all downloads with which it's 
not that noticeable. The runs I do are executing around 900 tests and it's not 
a proper performance test with a warmup and multiple identical runs on 
identical hardware.

Therefore the additional tests on our setup doesn't make much sense I assume, 
as the issue we had is fixed once merged to the latest Maven core.

You also mentioned that you have an IT that reproduces the issue which can be 
used to assure that you don't add a regression.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.6.3, 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17338775#comment-17338775
 ] 

Guy Brand commented on MRESOLVER-153:
-

Works as expected after multiple runs! Thanks for fixing it.

Do you have a timeline when this change will be available in the Maven core 
4.0.0 snapshot? Once this is released we can remove our current 
{{-Daether.metadataResolver.threads=1}} workaround which would then also speed 
up our tests again.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> 

[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332937#comment-17332937
 ] 

Guy Brand edited comment on MRESOLVER-153 at 4/27/21, 5:31 AM:
---

I've executed the tests and extracted two that failed with the above error. One 
is with the {{-Daether.syncContext.impl=global}} system property set and one 
without.

Just read the above comments and nice that you could find the root cause. I 
hope with these logs you can verify it. Do you need anything else from me?

 

[^with-global-sync-context.txt] [^without-global-sync-context.txt]


was (Author: brand):
I've executed the tests and extracted two that failed with the above error. One 
is with the {{-Daether.syncContext.impl=global}} system property set and one 
without.

Just read the above comments and nice that you could find the root cause. I 
hope with these logs you can verify it. Do you need anything else from me?

 

[^with-global-sync-context.txt] [^without-global-sync-context.txt]

[^with-global-sync-context.txt]

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback, 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at 

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guy Brand updated MRESOLVER-153:

Attachment: without-global-sync-context.txt
with-global-sync-context.txt

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback, 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the {{Properties#load()}} method wich then throws the 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332937#comment-17332937
 ] 

Guy Brand commented on MRESOLVER-153:
-

I've executed the tests and extracted two that failed with the above error. One 
is with the {{-Daether.syncContext.impl=global}} system property set and one 
without.

Just read the above comments and nice that you could find the root cause. I 
hope with these logs you can verify it. Do you need anything else from me?

 

[^with-global-sync-context.txt] [^without-global-sync-context.txt]

[^with-global-sync-context.txt]

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback, 1.7.0
>
> Attachments: screenshot-1.png, with-global-sync-context.txt, 
> without-global-sync-context.txt
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332611#comment-17332611
 ] 

Guy Brand commented on MRESOLVER-153:
-

So then I'll just run the tests again with {{-Daether.syncContext.impl=global}} 
set? Or should I also run it with what you explained here 
https://issues.apache.org/jira/browse/MRESOLVER-153?focusedCommentId=17332568=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17332568
 ? 

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback, 1.7.0
>
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17332501#comment-17332501
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] Thanks a lot for providing a custom distribution. This made it 
easy to rerun all our tests based on this Maven version. I reran all our tests 
on Linux, Windows and OSX. We still face these issues on all operating systems, 
but the most occurrences are on OSX (as initially reported). So in short this 
still does not work as expected.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Fix For: waiting-for-feedback, 1.7.0
>
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312705#comment-17312705
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] What is the status of this issue? Does it occur on the release 
version still? If yes, when can this be fixed such that we can run our 
integration tests with the default amount of resolver threads again?

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17270843#comment-17270843
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] Did that happen on the MRESOLVER-145 custom Maven build you 
referenced above? I still could not add this automated step into our CI.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the {{Properties#load()}} method wich then throws the 
> above error. See 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256553#comment-17256553
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] Not sure how to do this as the referenced PR is from the Maven 
Resolver project and not from [https://github.com/apache/maven] from which we 
create our nightly snapshots via CI. If you can provide a custom branch on that 
repo with these changes I can trigger our suite based on these changes. 
Manually building it is not an option for us, as we have everything automated 
in CI and only rely on artifacts published by CI.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17256383#comment-17256383
 ] 

Guy Brand commented on MRESOLVER-153:
-

I'm happy to help out. We can run our set of tests with changes on master. We 
publish our own Maven nightlies based on the {{master}} branch to our own 
infrastructure. We may be able to do a custom snapshot from a branch where the 
new Maven resolver version is included. If you can provide such a branch we can 
use it for the tests.

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now 

[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17255522#comment-17255522
 ] 

Guy Brand commented on MRESOLVER-153:
-

[~michael-o] Regarding

> Why do you pass {{-Daether.updateCheckManager.sessionState=false}}? What 
> happens when you leave this out?

With this flag set, the problem is reproducible more often as it will check the 
dependencies every time and doesn't store it in the session.

> Can you try {{-Daether.metadataResolver.threads=1}} for testing purposes?

I executed a run of all our integration tests and they passed. We'll then keep 
this flag set until this is fixed in a future Maven nightly version.

Regarding the synchronization: There you already discussed on how to restore 
it. My two cents on that topic are the following:

There is the concept of a {{SyncContext}} and components as the 
{{TrackingFileManager}} rely on this to implement proper synchronization. Why 
having a {{DefaultSyncContext}} in place that does no synchronization at all? 
Having this noop {{SyncContext}} could produce other errors like the one I 
reported. Therefore instead of checking if the {{DefaultSyncContext}} is used 
in the {{TrackingFileManager}}, why not just implement basic synchronization in 
the {{DefaultSyncContext, }}rely on it and on top prevent similar errors on the 
other usages of {{SyncContext}}?

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Assignee: Michael Osipov
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guy Brand updated MRESOLVER-153:

Attachment: screenshot-1.png

> resolver-status.properties file is corrupted due to concurrent writes
> -
>
> Key: MRESOLVER-153
> URL: https://issues.apache.org/jira/browse/MRESOLVER-153
> Project: Maven Resolver
>  Issue Type: Bug
>  Components: Resolver
>Affects Versions: 1.6.1
> Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
>Reporter: Guy Brand
>Priority: Major
> Attachments: screenshot-1.png
>
>
> In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} 
> after [this 
> commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
>  we face the following error:
> {code:java}
> [main] [INFO] 
> 
> [main] [INFO] BUILD FAILURE
> [main] [INFO] 
> 
> [main] [INFO] Total time: 0.243 s
> [main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
> [main] [INFO] 
> 
> [main] [ERROR] Malformed \u encoding.
> java.lang.IllegalArgumentException: Malformed \u encoding.
>  at java.util.Properties.loadConvert (Properties.java:675)
>  at java.util.Properties.load0 (Properties.java:451)
>  at java.util.Properties.load (Properties.java:404)
>  at org.eclipse.aether.internal.impl.TrackingFileManager.read 
> (TrackingFileManager.java:56)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
> (DefaultUpdateCheckManager.java:511)
>  at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
> (DefaultUpdateCheckManager.java:250)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
> (DefaultMetadataResolver.java:302)
>  at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
> (DefaultMetadataResolver.java:181)
>  at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
> (DefaultRepositorySystem.java:277)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
>  (DefaultPluginVersionResolver.java:134)
>  at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
> (DefaultPluginVersionResolver.java:97)
>  at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
>  (LifecyclePluginResolver.java:67)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:104)
>  at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
>  (DefaultLifecycleTaskSegmentCalculator.java:86)
>  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
> (LifecycleStarter.java:92)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
>  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
>  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
>  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
>  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
>  at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
> (NativeMethodAccessorImpl.java:62)
>  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
> (DelegatingMethodAccessorImpl.java:43)
>  at java.lang.reflect.Method.invoke (Method.java:566)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
> (Launcher.java:282)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
> (Launcher.java:225)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
> (Launcher.java:406)
>  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
> {code}
> It's not consistently failing and OSX based CI agents fail more often than 
> Linux or Windows ones. After some investigations we saw that as part of 
> https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
> been removed on the {{TrackingFileManager}} 
> ([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
> concurrent writes on the {{resolver-status.properties}} file in our tests and 
> causes the error during the {{Properties#load()}} method wich then throws the 
> above error. See this screenshot on how these files look like (cannot add the 
> text here as {{null}} characters aren't shown):
> When enabling debug log we also see that the {{DefaultMetadataResolver}} 
> 

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guy Brand updated MRESOLVER-153:

Description: 
In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):

 !screenshot-1.png! 

When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [INFO] Downloading from custom-repo: 
https://repository.apache.org/snapshots/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [DEBUG] Writing tracking file 

[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

 [ 
https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guy Brand updated MRESOLVER-153:

Description: 
In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):



When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [INFO] Downloading from custom-repo: 
https://repository.apache.org/snapshots/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] [DEBUG] Writing tracking file 

[jira] [Created] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes

[Guy Brand (Jira)]

Guy Brand created MRESOLVER-153:
---

 Summary: resolver-status.properties file is corrupted due to 
concurrent writes
 Key: MRESOLVER-153
 URL: https://issues.apache.org/jira/browse/MRESOLVER-153
 Project: Maven Resolver
  Issue Type: Bug
  Components: Resolver
Affects Versions: 1.6.1
 Environment: OSX 11.1 on adoptopenjdk-11.0.8+10
Reporter: Guy Brand


In our integration tests which run with Maven {{4.0.0-alpha-1-SNAPSHOT}} after 
[this 
commit|https://github.com/apache/maven/commit/7c7de41562a8d83635e8fa21c3a3340298b508a1],
 we face the following error:
{code:java}
[main] [INFO] 

[main] [INFO] BUILD FAILURE
[main] [INFO] 

[main] [INFO] Total time: 0.243 s
[main] [INFO] Finished at: 2020-12-23T13:48:59+01:00
[main] [INFO] 

[main] [ERROR] Malformed \u encoding.
java.lang.IllegalArgumentException: Malformed \u encoding.
 at java.util.Properties.loadConvert (Properties.java:675)
 at java.util.Properties.load0 (Properties.java:451)
 at java.util.Properties.load (Properties.java:404)
 at org.eclipse.aether.internal.impl.TrackingFileManager.read 
(TrackingFileManager.java:56)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.read 
(DefaultUpdateCheckManager.java:511)
 at org.eclipse.aether.internal.impl.DefaultUpdateCheckManager.checkMetadata 
(DefaultUpdateCheckManager.java:250)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve 
(DefaultMetadataResolver.java:302)
 at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata 
(DefaultMetadataResolver.java:181)
 at org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveMetadata 
(DefaultRepositorySystem.java:277)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository
 (DefaultPluginVersionResolver.java:134)
 at 
org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve 
(DefaultPluginVersionResolver.java:97)
 at 
org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions
 (LifecyclePluginResolver.java:67)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:104)
 at 
org.apache.maven.lifecycle.internal.DefaultLifecycleTaskSegmentCalculator.calculateTaskSegments
 (DefaultLifecycleTaskSegmentCalculator.java:86)
 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:92)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:321)
 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:206)
 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:119)
 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:982)
 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:296)
 at org.apache.maven.cli.MavenCli.main (MavenCli.java:200)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke (Method.java:566)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:282)
 at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
 at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:406)
 at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
{code}
It's not consistently failing and OSX based CI agents fail more often than 
Linux or Windows ones. After some investigations we saw that as part of 
https://issues.apache.org/jira/browse/MRESOLVER-132 the synchronization has 
been removed on the {{TrackingFileManager}} 
([https://github.com/apache/maven-resolver/pull/67]). This now leads to 
concurrent writes on the {{resolver-status.properties}} file in our tests and 
causes the error during the {{Properties#load()}} method wich then throws the 
above error. See this screenshot on how these files look like (cannot add the 
text here as {{null}} characters aren't shown):

When enabling debug log we also see that the {{DefaultMetadataResolver}} 
threads try to write concurrently to this file:
{code:java}
[DefaultMetadataResolver-0-0] [INFO] Downloading from custom-repo2: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-2] [INFO] Downloading from central-proxy: 
https://repo.maven.apache.org/maven2/mng--concurrent-writes-to-resolver-status-file/plugin/maven-metadata.xml
[DefaultMetadataResolver-0-1] 

[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162215#comment-17162215
 ] 

Guy Brand commented on MNG-5760:


[~mthmulders] This is now fixed with the other pull request you created. Thanks 
for fixing it that quickly!

> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the 
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be 
> very useful if you could type {{mvn  -rf}} and have the project name 
> inferred from the last failure rather than needing to copy/paste from the 
> terminal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17144102#comment-17144102
 ] 

Guy Brand commented on MNG-5760:


[~mthmulders] Great to hear! Thanks a lot!

> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the 
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be 
> very useful if you could type {{mvn  -rf}} and have the project name 
> inferred from the last failure rather than needing to copy/paste from the 
> terminal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17143795#comment-17143795
 ] 

Guy Brand commented on MNG-5760:


This change introduces a [possible 
{{NullPointerException}}|https://github.com/apache/maven/pull/342/files#diff-27608ebc026789b242c47348ac37dabfR65]
 as the {{project}} retrieved 
[here|https://github.com/apache/maven/pull/342/files#diff-27608ebc026789b242c47348ac37dabfR84]
 (coming from 
[{{LifecycleExecutionException#getProject()}}|https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/lifecycle/LifecycleExecutionException.java#L74])
 can return {{null}}.

We face this error when executing our integration tests which execute {{mvn 
resources:resources}} without an existing project. With Maven {{3.6.3}} the 
following error is thrown: 
{code:java}
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.995 s
[INFO] Finished at: 2020-06-24T09:38:21+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-resources-plugin:3.1.0:resources (default-cli): 
Goal requires a project to execute but there is no POM in this directory 
(/foo). Please verify you invoked Maven from the correct directory. -> [Help 
1]{code}
Can this be fixed as part of that issue ? Shall I create another pull request 
or will you have a look at this [~mthmulders] ?

> Add `-r/--resume` to automatically resume from the last failure point
> -
>
> Key: MNG-5760
> URL: https://issues.apache.org/jira/browse/MNG-5760
> Project: Maven
>  Issue Type: Improvement
>  Components: Command Line
>Affects Versions: 3.2.5
>Reporter: Phillip Webb
>Assignee: Robert Scholte
>Priority: Trivial
> Fix For: 3.7.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently when a multi-module build fails the {{mvn}} command line prints the 
> following error:
> {noformat}
> [ERROR] After correcting the problems, you can resume the build with the 
> command
> [ERROR]   mvn  -rf :some-module-name
> {noformat}
> Since I almost always want to use this flag with the next build it would be 
> very useful if you could type {{mvn  -rf}} and have the project name 
> inferred from the last failure rather than needing to copy/paste from the 
> terminal.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1688) Junit Platform test with failing @BeforeAll does not fail the build

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17035272#comment-17035272
 ] 

Guy Brand commented on SUREFIRE-1688:
-

We tested it with our integration tests and the latest snapshot of {{master}} 
fixes it. Thanks for the fix!

> Junit Platform test with failing @BeforeAll does not fail the build
> ---
>
> Key: SUREFIRE-1688
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1688
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Surefire Plugin
>Reporter: Guy Brand
>Assignee: Tibor Digana
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When using Surefire {{3.0.0-SNAPSHOT}} and JUnit Platform {{5.4.2}} the 
> following test does not fail the Maven build. 
> {code:java}
> import org.junit.jupiter.api.Test;
> import org.junit.jupiter.api.BeforeAll;
> import org.junit.jupiter.api.Assertions;
> public class Tests {
> @BeforeAll
> public static void beforeAll() { Assertions.fail("BeforeAll fail"); }
> @Test
> public void test() { Assertions.fail("Test fail"); }
> }
> {code}
> And its output:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @ 
> top-level-project ---
> [INFO] 
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running Tests
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 
> s - in Tests
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> When removing the {{@BeforeAll}} annotation/method it fails as expected. 
> {{3.0.0-M3}} version of Surefire works as expected:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ 
> top-level-project ---
> [INFO] 
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running Tests
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.008 
> s <<< FAILURE! - in Tests
> [ERROR] Tests  Time elapsed: 0.007 s  <<< FAILURE!
> org.opentest4j.AssertionFailedError: BeforeAll fail
>   at Tests.beforeAll(Tests.java:7)
> [INFO] 
> [INFO] Results:
> [INFO] 
> [ERROR] Failures: 
> [ERROR]   Tests.beforeAll:7 BeforeAll fail
> [INFO] 
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  2.373 s
> [INFO] Finished at: 2019-08-20T16:20:16+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) 
> on project top-level-project: There are test failures.
> {code}
> For all the tests Maven 3.6.1 has been used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (SUREFIRE-1688) Junit Platform test with failing @BeforeAll does not fail the build

[Guy Brand (Jira)]

[ 
https://issues.apache.org/jira/browse/SUREFIRE-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16937436#comment-16937436
 ] 

Guy Brand commented on SUREFIRE-1688:
-

With a newer snapshot after the one I tested while reporting the issue was not 
present anymore. Could you close it as explained? Thanks.

> Junit Platform test with failing @BeforeAll does not fail the build
> ---
>
> Key: SUREFIRE-1688
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1688
> Project: Maven Surefire
>  Issue Type: Bug
>  Components: JUnit 5.x support, Maven Surefire Plugin
>Reporter: Guy Brand
>Priority: Major
>
> When using Surefire {{3.0.0-SNAPSHOT}} and JUnit Platform {{5.4.2}} the 
> following test does not fail the Maven build. 
> {code:java}
> import org.junit.jupiter.api.Test;
> import org.junit.jupiter.api.BeforeAll;
> import org.junit.jupiter.api.Assertions;
> public class Tests {
> @BeforeAll
> public static void beforeAll() { Assertions.fail("BeforeAll fail"); }
> @Test
> public void test() { Assertions.fail("Test fail"); }
> }
> {code}
> And its output:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @ 
> top-level-project ---
> [INFO] 
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running Tests
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 
> s - in Tests
> [INFO] 
> [INFO] Results:
> [INFO] 
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD SUCCESS
> [INFO] 
> 
> {code}
> When removing the {{@BeforeAll}} annotation/method it fails as expected. 
> {{3.0.0-M3}} version of Surefire works as expected:
> {code}
> [INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ 
> top-level-project ---
> [INFO] 
> [INFO] ---
> [INFO]  T E S T S
> [INFO] ---
> [INFO] Running Tests
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.008 
> s <<< FAILURE! - in Tests
> [ERROR] Tests  Time elapsed: 0.007 s  <<< FAILURE!
> org.opentest4j.AssertionFailedError: BeforeAll fail
>   at Tests.beforeAll(Tests.java:7)
> [INFO] 
> [INFO] Results:
> [INFO] 
> [ERROR] Failures: 
> [ERROR]   Tests.beforeAll:7 BeforeAll fail
> [INFO] 
> [ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
> [INFO] 
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time:  2.373 s
> [INFO] Finished at: 2019-08-20T16:20:16+02:00
> [INFO] 
> 
> [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) 
> on project top-level-project: There are test failures.
> {code}
> For all the tests Maven 3.6.1 has been used.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SUREFIRE-1688) Junit Platform test with failing @BeforeAll does not fail the build

[Guy Brand (Jira)]

Guy Brand created SUREFIRE-1688:
---

 Summary: Junit Platform test with failing @BeforeAll does not fail 
the build
 Key: SUREFIRE-1688
 URL: https://issues.apache.org/jira/browse/SUREFIRE-1688
 Project: Maven Surefire
  Issue Type: Bug
  Components: JUnit 5.x support, Maven Surefire Plugin
Reporter: Guy Brand


When using Surefire {{3.0.0-SNAPSHOT}} and JUnit Platform {{5.4.2}} the 
following test does not fail the Maven build. 

{code:java}
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.Assertions;
public class Tests {

@BeforeAll
public static void beforeAll() { Assertions.fail("BeforeAll fail"); }

@Test
public void test() { Assertions.fail("Test fail"); }
}
{code}

And its output:

{code}
[INFO] --- maven-surefire-plugin:3.0.0-SNAPSHOT:test (default-test) @ 
top-level-project ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running Tests
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 s 
- in Tests
[INFO] 
[INFO] Results:
[INFO] 
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
{code}

When removing the {{@BeforeAll}} annotation/method it fails as expected. 

{{3.0.0-M3}} version of Surefire works as expected:

{code}
[INFO] --- maven-surefire-plugin:3.0.0-M3:test (default-test) @ 
top-level-project ---
[INFO] 
[INFO] ---
[INFO]  T E S T S
[INFO] ---
[INFO] Running Tests
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.008 s 
<<< FAILURE! - in Tests
[ERROR] Tests  Time elapsed: 0.007 s  <<< FAILURE!
org.opentest4j.AssertionFailedError: BeforeAll fail
at Tests.beforeAll(Tests.java:7)

[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Failures: 
[ERROR]   Tests.beforeAll:7 BeforeAll fail
[INFO] 
[ERROR] Tests run: 1, Failures: 1, Errors: 0, Skipped: 0
[INFO] 
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  2.373 s
[INFO] Finished at: 2019-08-20T16:20:16+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M3:test (default-test) on 
project top-level-project: There are test failures.
{code}

For all the tests Maven 3.6.1 has been used.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Commented] (MNG-6558) ToolchainsBuildingResult event is not sent on EventSpy

[Guy Brand (JIRA)]

[ 
https://issues.apache.org/jira/browse/MNG-6558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16753394#comment-16753394
 ] 

Guy Brand commented on MNG-6558:


[~slachiewicz] Thanks for merging it that quickly!

> ToolchainsBuildingResult event is not sent on EventSpy
> --
>
> Key: MNG-6558
> URL: https://issues.apache.org/jira/browse/MNG-6558
> Project: Maven
>  Issue Type: Bug
>Affects Versions: 3.6.0
>Reporter: Guy Brand
>Assignee: Sylwester Lachiewicz
>Priority: Major
> Fix For: 3.6.1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> On the {{EventSpy}} we get the {{ToolchainsBuildingRequest}} event twice and 
> the {{ToolchainsBuildingResult}} is not sent. The problem is 
> [here|https://github.com/apache/maven/blob/master/maven-embedder/src/main/java/org/apache/maven/cli/MavenCli.java#L1268]
>  where the {{ToolchainsBuildingRequest}} event is sent twice to the 
> {{eventSpyDispatcher}} instead of the {{ToolchainsBuildingResult}} event.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)