[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 t
[jira] [Commented] (MSHARED-993) Make MessageUtils resilient to failures during uninstall
[ https://issues.apache.org/jira/browse/MSHARED-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Created] (MSHARED-993) Make MessageUtils resilient to failures during uninstall
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
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > we
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 th
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MNG-7161) Error thrown during uninstalling of JAnsi
[ https://issues.apache.org/jira/browse/MNG-7161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 a
[jira] [Created] (MNG-7161) Error thrown during uninstalling of JAnsi
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
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 mo
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.ma
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{TrackingFile
[jira] [Comment Edited] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 org.codehaus.plexus
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ 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
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 investigati
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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&page=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}} > ([https://github.com/apach
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 {{TrackingFi
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 err
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > abov
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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]
[jira] [Commented] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ https://issues.apache.org/jira/browse/MRESOLVER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 > (NativeMethodAccessorIm
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ 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}} > threads
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ 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 /.../core-it-suite/target/test-cla
[jira] [Updated] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
[ 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 /.../core-it-suite/target/test-classes/mng--concur
[jira] [Created] (MRESOLVER-153) resolver-status.properties file is corrupted due to concurrent writes
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] [I
[jira] [Commented] (MNG-5760) Add `-r/--resume` to automatically resume from the last failure point
[ https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/MNG-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SUREFIRE-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/SUREFIRE-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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
[ https://issues.apache.org/jira/browse/MNG-6558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)