[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693584#comment-17693584
]
Christoph Läubrich commented on MRESOLVER-325:
--
[~michael-o] many thanks for your detailed analysis!
I think this should really be reported to JDK as it seems to hurt many projects
with a lot of hacks and workarounds (that's as you have proven probably don't
work at all)!
For Resolver, I think the idea is that if the process is killed "in the middle"
we do not leave a half written garbage file, for that case I wonder if a simple
delete-then-move won't work equally good, atomic file operations sound good at
the first place but are hard to guarantee as we see here.
So there are some strategies:
* You can (as suggested) just write directly to the file and make the read more
robust, and simply discard data in the case something goes wrong (I think
that's always good, because error can happen always but one should be able to
recover from them)
* Additionally if one wants can use some rolling file strategy, instead of
writing to _remote.repositories you write to _remote..repositories where
is incremented on each write, so the process is then: find current index >
write to temp > rename file to next index > delete last index ... but thats
probably a way to much here as it also has impact on reading to find the
current valid index
So I would most probably go for (1) here the worst that can happen is that
resolver the file is not up-to-date and download it again, something that would
also happen if the file was deleted by the user or maybe an request to update
it ... so its actually something that can already be handled and only should
happen if previously something gone wrong in which case it might be better to
start fresh anyways.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at
[GitHub] [maven-surefire] s-rwe commented on pull request #615: [SUREFIRE-2152] Include name of JUnit5 templated-tests in test description
s-rwe commented on PR #615: URL: https://github.com/apache/maven-surefire/pull/615#issuecomment-1445250680 > Please check result of ITs - and fix ITs or code according I'd be happy to, but I'm unable to run the ITs locally to do this in the first place (as mentioned above in my initial description) Couple of things I did: * Followed the steps outlined https://github.com/apache/maven-surefire#development-information * Disabled rat-checks with `-Drat.skip=true` (those also failed quickly at first) * `mvn -Prun-its clean install` always fails, as mentioned before in the PR description * Same failure also happens for me on master (namely, I tried it on 208eae24b) - so unrelated to the changes of this PR * Tried a few JDKs too (namely, corretto 19 and 1.8) Not to speak of trying to get specific tests to run in IntelliJ to get them fixed (I have a different set of issues here) - but would be nice to at least be able to run things from commandline via mvn. So I'm kind of stuck on that end, tips / hints anyone? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693560#comment-17693560
]
Tamas Cservenak commented on MRESOLVER-325:
---
Please create a PR
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> at
> org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve
> (MavenDependenciesResolverConfigurer.java:104)
> at org.eclipse.tycho.core.shared.MavenDependenciesResolver.resolve
> (MavenDependenciesResolver.java:60)
> at org.eclipse.tycho.core.resolver.MavenTargetDefinitionContent.
> (MavenTargetDefinitionContent.java:262)
> at
>
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693559#comment-17693559
]
Michael Osipov commented on MRESOLVER-325:
--
This works for me on Windows reliably:
{noformat}
PS C:\Entwicklung\Projekte\maven-resolver> git --no-pager diff -U0
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java
index d9385cbe..57893adf 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultFileProcessor.java
@@ -39 +38,0 @@ import org.eclipse.aether.util.ChecksumUtils;
-import org.eclipse.aether.util.FileUtils;
@@ -92 +91 @@ public class DefaultFileProcessor
-FileUtils.writeFile( target.toPath(), p -> Files.write( p,
data.getBytes( StandardCharsets.UTF_8 ) ) );
+Files.write( target.toPath(), data.getBytes( StandardCharsets.UTF_8 )
);
@@ -98 +97 @@ public class DefaultFileProcessor
-FileUtils.writeFile( target.toPath(), p -> Files.copy( source, p,
StandardCopyOption.REPLACE_EXISTING ) );
+Files.copy( source, target.toPath(),
StandardCopyOption.REPLACE_EXISTING );
@@ -111,2 +110 @@ public class DefaultFileProcessor
- FileUtils.CollocatedTempFile tempTarget = FileUtils.newTempFile(
target.toPath() );
- OutputStream out = new BufferedOutputStream(
Files.newOutputStream( tempTarget.getPath() ) ) )
+ OutputStream out = new BufferedOutputStream(
Files.newOutputStream( target.toPath() ) ) )
@@ -115 +112,0 @@ public class DefaultFileProcessor
-tempTarget.move();
diff --git
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java
index 4269ce98..32ab1841 100644
---
a/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java
+++
b/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java
@@ -35 +34,0 @@ import java.util.Properties;
-import org.eclipse.aether.util.FileUtils;
@@ -53 +52 @@ public final class DefaultTrackingFileManager
-if ( Files.isRegularFile( filePath ) )
+if ( Files.isReadable( filePath ) )
@@ -108 +107 @@ public final class DefaultTrackingFileManager
-FileUtils.writeFile( filePath, p ->
+if ( Files.isWritable( filePath ) )
@@ -110 +109 @@ public final class DefaultTrackingFileManager
-try ( OutputStream stream = Files.newOutputStream( p ) )
+try ( OutputStream stream = Files.newOutputStream( filePath ) )
@@ -116 +115 @@ public final class DefaultTrackingFileManager
-} );
+}
{noformat}
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
>
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693558#comment-17693558
]
Tamas Cservenak commented on MRESOLVER-325:
---
Am unsure to remove something that is broken on Windows. Linux, macOS, BSD
works ok, no?
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> at
> org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve
> (MavenDependenciesResolverConfigurer.java:104)
> at org.eclipse.tycho.core.shared.MavenDependenciesResolver.resolve
> (MavenDependenciesResolver.java:60)
> at org.eclipse.tycho.core.resolver.MavenTargetDefinitionContent.
> (MavenTargetDefinitionContent.java:262)
>
[jira] [Comment Edited] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693556#comment-17693556
]
Michael Osipov edited comment on MRESOLVER-325 at 2/26/23 12:14 AM:
Unless someone has a bright idea I would opt to remove the entire write to temp
file and then move since it is just broken on Windows IF there is not bug in
our code with open FDs.
We have named locks in place, all target files should be under lock protection.
was (Author: michael-o):
Unless someone has a bright idea I would opt to remove the entire write to temp
file and then move since it is just broken on Windows IF there is not bug in
our code with open FDs.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693556#comment-17693556
]
Michael Osipov commented on MRESOLVER-325:
--
Unless someone has a bright idea I would opt to remove the entire write to temp
file and then move since it is just broken on Windows IF there is not bug in
our code with open FDs.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> at
> org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve
> (MavenDependenciesResolverConfigurer.java:104)
> at org.eclipse.tycho.core.shared.MavenDependenciesResolver.resolve
> (MavenDependenciesResolver.java:60)
> at
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693555#comment-17693555
]
Michael Osipov commented on MRESOLVER-325:
--
I have tried to add a sleep of 5000 ms between two tried of atomic moves, no
avail. Still fails. What I don't understand: either the FD is still open due to
a bug from us OR how long takes {{MoveFileEx}} to complete here.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> at
> org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve
> (MavenDependenciesResolverConfigurer.java:104)
> at org.eclipse.tycho.core.shared.MavenDependenciesResolver.resolve
>
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[ https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693550#comment-17693550 ] ASF GitHub Bot commented on MRESOLVER-329: -- michael-o commented on PR #257: URL: https://github.com/apache/maven-resolver/pull/257#issuecomment-1445224171 Does not work and suffers from the chicken and egg problem described in here: https://issues.apache.org/jira/browse/MRESOLVER-325?focusedCommentId=17693545=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17693545 > Make IO in DefaultTrackingFileManager more robust > - > > Key: MRESOLVER-329 > URL: https://issues.apache.org/jira/browse/MRESOLVER-329 > Project: Maven Resolver > Issue Type: Improvement > Components: Resolver >Reporter: Tamas Cservenak >Assignee: Tamas Cservenak >Priority: Major > Fix For: 1.9.6 > > > There are couple of spots where implementation naively assumes is alone > running process on this world. Several user reports suggests this is not the > case, like MRESOLVER-325 or MNG-7705. Fix these spots. > Still, something is fishy, as it seems these files (all that are handled by > DefaultTrackingFileManager) are not subject to locking? This needs > investigation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [maven-resolver] michael-o commented on pull request #257: [MRESOLVER-329] More robust IO in DefaultTrackingFileManager
michael-o commented on PR #257: URL: https://github.com/apache/maven-resolver/pull/257#issuecomment-1445224171 Does not work and suffers from the chicken and egg problem described in here: https://issues.apache.org/jira/browse/MRESOLVER-325?focusedCommentId=17693545=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17693545 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-resolver] michael-o commented on a diff in pull request #257: [MRESOLVER-329] More robust IO in DefaultTrackingFileManager
michael-o commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117990047
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java:
##
@@ -75,6 +76,8 @@ public Properties update(File file, Map
updates) {
if (Files.isReadable(filePath)) {
try (InputStream stream = Files.newInputStream(filePath)) {
props.load(stream);
+} catch (NoSuchFileException e) {
+// MRESOLVER-329: ignore; in case of concurrent r/w
Files.isReadable may return true
Review Comment:
Please move this to another PR, both issues aren't necessarily related.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -105,7 +106,16 @@ public Path getPath() {
@Override
public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+try {
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+} catch (AccessDeniedException e) {
+// MRESOLVER-329: fallback to plain copy+rm, this usually
happens on Windows
Review Comment:
MRESOLVER-325 and not 329
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MRESOLVER-329) Make IO in DefaultTrackingFileManager more robust
[
https://issues.apache.org/jira/browse/MRESOLVER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693549#comment-17693549
]
ASF GitHub Bot commented on MRESOLVER-329:
--
michael-o commented on code in PR #257:
URL: https://github.com/apache/maven-resolver/pull/257#discussion_r1117990047
##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultTrackingFileManager.java:
##
@@ -75,6 +76,8 @@ public Properties update(File file, Map
updates) {
if (Files.isReadable(filePath)) {
try (InputStream stream = Files.newInputStream(filePath)) {
props.load(stream);
+} catch (NoSuchFileException e) {
+// MRESOLVER-329: ignore; in case of concurrent r/w
Files.isReadable may return true
Review Comment:
Please move this to another PR, both issues aren't necessarily related.
##
maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java:
##
@@ -105,7 +106,16 @@ public Path getPath() {
@Override
public void move() throws IOException {
-Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+try {
+Files.move(tempFile, file, StandardCopyOption.ATOMIC_MOVE);
+} catch (AccessDeniedException e) {
+// MRESOLVER-329: fallback to plain copy+rm, this usually
happens on Windows
Review Comment:
MRESOLVER-325 and not 329
> Make IO in DefaultTrackingFileManager more robust
> -
>
> Key: MRESOLVER-329
> URL: https://issues.apache.org/jira/browse/MRESOLVER-329
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
>Reporter: Tamas Cservenak
>Assignee: Tamas Cservenak
>Priority: Major
> Fix For: 1.9.6
>
>
> There are couple of spots where implementation naively assumes is alone
> running process on this world. Several user reports suggests this is not the
> case, like MRESOLVER-325 or MNG-7705. Fix these spots.
> Still, something is fishy, as it seems these files (all that are handled by
> DefaultTrackingFileManager) are not subject to locking? This needs
> investigation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693547#comment-17693547
]
Michael Osipov commented on MRESOLVER-325:
--
with REPLACE_EXISTING:
{noformat}
413730 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\_remote.repositories'
413730 [main] [WARNING] Failed to write tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\_remote.repositories'
java.nio.file.FileSystemException:
C:\temp\repo\com\google\code\gson\gson\2.10.1\_remote.repositories: Der Prozess
kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet
wird
at sun.nio.fs.WindowsException.translateToIOException
(WindowsException.java:92)
at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:103)
at sun.nio.fs.WindowsException.rethrowAsIOException
(WindowsException.java:108)
at sun.nio.fs.WindowsFileCopy.move (WindowsFileCopy.java:392)
at sun.nio.fs.WindowsFileSystemProvider.move
(WindowsFileSystemProvider.java:293)
at java.nio.file.Files.move (Files.java:1432)
{noformat}
This is caused by {{DeleteFile(targetPath);}} in JDK code since this file is
locked by the previous, still pending, run if {{MoveFileEx(sourcePath,
targetPath, 0);}} fails.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
>
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693545#comment-17693545
]
Michael Osipov commented on MRESOLVER-325:
--
OK, I cracked it. This is purely a Windows problem, any system which adheres to
POSIX is supposed to implement {{rename(2)}} atomic:
https://pubs.opengroup.org/onlinepubs/95399/functions/rename.html.
Now, the code for Windows does this:
https://github.com/openjdk/jdk17u-dev/blob/aa11a935373686bf5d67afb89368931c995824f6/src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java#L307-L320
{{MoveFileEx}} does not mention anything about atomic. Interesting read:
https://github.com/python/cpython/issues/53074. My testing even with single
thread leads to the assumption that {{MoveFileEx}} is executed delayed and
fails under high/fast load which means that the target file is blocked while
the next operation is already trying to overwrite it again and it fails. So
{{MoveFileEx}} returns although the move isn't complete.
To verify this I have applied the following patch:
{noformat}
diff --git
a/maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java
b/maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java
index f12d5b82..8b4a1960 100644
--- a/maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java
+++ b/maven-resolver-util/src/main/java/org/eclipse/aether/util/FileUtils.java
@@ -26,6 +26,10 @@ import java.nio.file.Path;
import java.nio.file.StandardCopyOption;
import java.util.concurrent.ThreadLocalRandom;
+import com.sun.jna.platform.win32.Kernel32;
+import com.sun.jna.platform.win32.WinBase;
+import com.sun.jna.platform.win32.WinDef.DWORD;
+
import static java.util.Objects.requireNonNull;
/**
@@ -118,7 +122,8 @@ public final class FileUtils
@Override
public void move() throws IOException
{
-Files.move( tempFile, file, StandardCopyOption.ATOMIC_MOVE );
+Kernel32.INSTANCE.MoveFileEx(
tempFile.toAbsolutePath().toString(), file.toAbsolutePath().toString(),
+new DWORD( WinBase.MOVEFILE_REPLACE_EXISTING |
WinBase.MOVEFILE_WRITE_THROUGH ) );
}
@Override
{noformat}
{{MOVEFILE_WRITE_THROUGH}} guarantees that the method does *not* exit before
the operation is complete. Which is actually what we need. With that patch
single thread and multi thread executions ran multiple times without issues.
So, [~laeubi], nothing is wrong with Tycho. the Java implementation is just
CRAP.
What now? Well, I replaced ATOMIC with REPLACE_EXISTING, now if you look at
that code in JDK it will delete the target which might be subject to move from
a previous run and then use again {{MoveFileEx}} without any flags which is
again non-blocking and we are back to the previous problem causing a chicken
and egg problem. Again, this is under high volume like here. This fails with
exceptions as well.
Why actually gson? Well, gson JAR AND gson sources JAR are downloaded with a
diff of a few hundred milliseconds and Windows cannot handle this. WHAT A JOKE.
While the additional flag won't make fully atomic, there is another function
for this, it reduces the possible failure to a minimum.
Thoughts?
PS: This needs to be reported with the OpenJDK team. Many others have suffered
from this because of the missing flags.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at
[GitHub] [maven-mvnd] lppedd commented on pull request #784: Make Classworld setup more alike to vanilla Maven
lppedd commented on PR #784: URL: https://github.com/apache/maven-mvnd/pull/784#issuecomment-1445194111 @oehme hi! Just passing by and wondering, in which case a plugin/extension would want to explicitly check for a class loader type? Did you think about this because of some real world use case? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] psiroky commented on a diff in pull request #238: [MNG-7661] Fix few build / compiler warnings
psiroky commented on code in PR #238: URL: https://github.com/apache/maven-integration-testing/pull/238#discussion_r1117965421 ## core-it-support/core-it-javaagent/pom.xml: ## @@ -53,6 +53,17 @@ under the License. shade + + + + *:* + +module-info.class +META-INF/MANIFEST.MF Review Comment: Nice catch, thanks! I would have hoped that "something" would fail the build if those manifest entries are missing -- seeing the linked PR, I assume this is only failing with Maven 4.x, which is currently not part of PR checks. In any case, I adjusted the filter to exclude only the `asm` artifacts, which should fix the issue (the build still won't pass with Maven 4.x, but the reported errors/failures seem to be consistent with the ones I am seeing on master branch) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693516#comment-17693516
]
Michael Osipov commented on MRESOLVER-325:
--
It even fails in serial mode:
{noformat}
442639 [main] [TRACE] Need 1 write lock(s) for
[artifact:com.google.code.gson:gson:2.10.1]
442640 [main] [TRACE] Acquiring write lock for
'artifact:com.google.code.gson:gson:2.10.1'
442640 [main] [TRACE] Total locks acquired: 1
442640 [main] [DEBUG] Resolving artifact com.google.code.gson:gson:jar:2.10.1
from [lda-public
(https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/,
default, releases+snapshots), dynamowerk-public
(https://deblndw011x.ad001.siemens.net/nexus/content/groups/dynamowerk-public/,
default, releases+snapshots), eclipse-hosted
(https://repo.eclipse.org/content/repositories/eclipse/, default,
releases+snapshots), eclipse
(https://download.eclipse.org/eclipse/updates/4.27-I-builds, p2, disabled),
central-mirror
(https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/,
default, releases)]
442642 [main] [DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/
442642 [main] [DEBUG] Using connector BasicRepositoryConnector with priority
0.0 for https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/
with username=osipovmi, password=***
442642 [main] [INFO] Downloading from lda-public:
https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar
442709 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\gson-2.10.1.jar.lastUpdated'
442724 [main] [DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://deblndw011x.ad001.siemens.net/nexus/content/groups/dynamowerk-public/
442724 [main] [DEBUG] Using connector BasicRepositoryConnector with priority
0.0 for
https://deblndw011x.ad001.siemens.net/nexus/content/groups/dynamowerk-public/
with username=osipovmi, password=***
442724 [main] [INFO] Downloading from dynamowerk-public:
https://deblndw011x.ad001.siemens.net/nexus/content/groups/dynamowerk-public/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar
442783 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\gson-2.10.1.jar.lastUpdated'
442792 [main] [DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://repo.eclipse.org/content/repositories/eclipse/
442792 [main] [DEBUG] Using connector BasicRepositoryConnector with priority
0.0 for https://repo.eclipse.org/content/repositories/eclipse/
442793 [main] [INFO] Downloading from eclipse-hosted:
https://repo.eclipse.org/content/repositories/eclipse/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar
442920 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\gson-2.10.1.jar.lastUpdated'
442926 [main] [DEBUG] Using transporter HttpTransporter with priority 5.0 for
https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/
442927 [main] [DEBUG] Using connector BasicRepositoryConnector with priority
0.0 for
https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/ with
username=osipovmi, password=***
442927 [main] [INFO] Downloading from central-mirror:
https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar
443167 [main] [INFO] Downloaded from central-mirror:
https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar
(283 kB at 1.2 MB/s)
443168 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\_remote.repositories'
443172 [main] [DEBUG] Writing tracking file
'C:\temp\repo\com\google\code\gson\gson\2.10.1\gson-2.10.1.jar.lastUpdated'
443174 [main] [TRACE] Releasing write lock for
'artifact:com.google.code.gson:gson:2.10.1'
443174 [main] [TRACE] Total locks released: 1
443218 [main] [TRACE] Need 1 write lock(s) for
[artifact:com.google.code.gson:gson:2.10.1]
443218 [main] [TRACE] Acquiring write lock for
'artifact:com.google.code.gson:gson:2.10.1'
443218 [main] [TRACE] Total locks acquired: 1
443219 [main] [DEBUG] Resolving artifact
com.google.code.gson:gson:jar:sources:2.10.1 from [lda-public
(https://deblndw011x.ad001.siemens.net/nexus/content/groups/lda-public/,
default, releases+snapshots), dynamowerk-public
(https://deblndw011x.ad001.siemens.net/nexus/content/groups/dynamowerk-public/,
default, releases+snapshots), eclipse-hosted
(https://repo.eclipse.org/content/repositories/eclipse/, default,
releases+snapshots), eclipse
(https://download.eclipse.org/eclipse/updates/4.27-I-builds, p2, disabled),
central-mirror
(https://deblndw011x.ad001.siemens.net/nexus/content/repositories/central/,
default, releases)]
443220 [main]
[jira] [Commented] (MRESOLVER-325) [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
[
https://issues.apache.org/jira/browse/MRESOLVER-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693510#comment-17693510
]
Michael Osipov commented on MRESOLVER-325:
--
Note: The static locks do not change anything. It still fails, I don't consider
this a bug in our code ATM, rather than a fuckup in Windows and NTFS not able
to give any guarantees. I am trying out a few things.
> [REGRESSION] Suddenly seeing I/O errors under windows aborting the build
>
>
> Key: MRESOLVER-325
> URL: https://issues.apache.org/jira/browse/MRESOLVER-325
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
>Affects Versions: 1.9.4
>Reporter: Christoph Läubrich
>Priority: Major
> Fix For: 1.9.6
>
>
> If one runs a build that otherwise works fine on 3.8.x with 3.9 we now get
> the following exception (full output can be found here
> https://github.com/eclipse-platform/eclipse.platform/actions/runs/4211467991/jobs/7309831666):
> {code:java}
> Error: 5.889 [ERROR] Internal error: java.io.UncheckedIOException:
> java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:108)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:821)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:270)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:77)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:568)
> 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)
> Caused by: java.io.UncheckedIOException: java.nio.file.AccessDeniedException:
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories.15650462061630955031.tmp
> ->
> C:\Users\runneradmin\.m2\repository\com\google\code\gson\gson\2.10.1\_remote.repositories
> at org.eclipse.aether.internal.impl.DefaultTrackingFileManager.update
> (DefaultTrackingFileManager.java:121)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addRepo
> (EnhancedLocalRepositoryManager.java:274)
> at
> org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.addArtifact
> (EnhancedLocalRepositoryManager.java:252)
> at org.eclipse.aether.internal.impl.EnhancedLocalRepositoryManager.add
> (EnhancedLocalRepositoryManager.java:225)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.evaluateDownloads
> (DefaultArtifactResolver.java:680)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.performDownloads
> (DefaultArtifactResolver.java:592)
> at org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:478)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts
> (DefaultArtifactResolver.java:278)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact
> (DefaultArtifactResolver.java:255)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact
> (DefaultRepositorySystem.java:296)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:197)
> at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve
> (DefaultArtifactResolver.java:413)
> at org.apache.maven.repository.legacy.LegacyRepositorySystem.resolve
> (LegacyRepositorySystem.java:332)
> at
> org.eclipse.tycho.osgi.configuration.MavenDependenciesResolverConfigurer.resolve
> (MavenDependenciesResolverConfigurer.java:104)
> at org.eclipse.tycho.core.shared.MavenDependenciesResolver.resolve
>
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693491#comment-17693491
]
ASF GitHub Bot commented on MNG-7700:
-
dmlloyd commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117940782
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
This is not really a useful test. You're just testing that the output is
what the output is. If you do this instead, you'll see that the "canonical"
version is not really a canonical version at all:
```java
ComparableVersion version = new ComparableVersion("0.x");
ComparableVersion canonical = new ComparableVersion(version.getCanonical());
assertEquals(canonical, version); // actually see if the *versions* are equal
```
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> |{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] dmlloyd commented on a diff in pull request #1014: [MNG-7700] test some edge cases with leading zeroes
dmlloyd commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117940782
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
This is not really a useful test. You're just testing that the output is
what the output is. If you do this instead, you'll see that the "canonical"
version is not really a canonical version at all:
```java
ComparableVersion version = new ComparableVersion("0.x");
ComparableVersion canonical = new ComparableVersion(version.getCanonical());
assertEquals(canonical, version); // actually see if the *versions* are equal
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693480#comment-17693480
]
ASF GitHub Bot commented on MNG-7700:
-
michael-o commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117932771
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
Depressing...
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> |{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1014: [MNG-7700] test some edge cases with leading zeroes
michael-o commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117932771
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
Depressing...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693478#comment-17693478
]
ASF GitHub Bot commented on MNG-7700:
-
elharo commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117930896
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
We never define or promise anything about the canonical representation of a
ComparableVersion. Indeed, this method probably shouldn't have been public. All
we promise is that two of them compare according to spec, and as best I can
tell they do. For now this is just a characterization test of existing
behavior. I'm leaving MNG-7700 open in case folks feel we should change the
canonical representation. However neither that issue nor this PR needs to block
the release.
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> |{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] elharo commented on a diff in pull request #1014: [MNG-7700] test some edge cases with leading zeroes
elharo commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117930896
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
We never define or promise anything about the canonical representation of a
ComparableVersion. Indeed, this method probably shouldn't have been public. All
we promise is that two of them compare according to spec, and as best I can
tell they do. For now this is just a characterization test of existing
behavior. I'm leaving MNG-7700 open in case folks feel we should change the
canonical representation. However neither that issue nor this PR needs to block
the release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Closed] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold closed MNG-7701.
--
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elliotte Rusty Harold resolved MNG-7701.
Resolution: Invalid
As best I can tell, the 3.8.7 behavior is correct in all cases. It might indeed
have changed since 3.8.6 but if so, it's 3.8.6 that was not behaving according
to spec.
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693476#comment-17693476
]
Elliotte Rusty Harold commented on MNG-7701:
Hmm,
underscore is ascii 95
x is ascii 120
so _x does sort lexicographically before x. That is, I was wrong when I said
"Underscore comes after all alphabetic characters in lexicographic order. 1_y
is effectively the same as 1._y."
It is a little tricky because capital X comes before x but we normalize to
lower case. Thus the 3.8.7 behavior is correct and expected.
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693475#comment-17693475
]
Elliotte Rusty Harold edited comment on MNG-7701 at 2/25/23 1:56 PM:
-
This bug appears valid. This test currently fails at head:
@Test
public void testMNG7701() {
ComparableVersion c1 = new ComparableVersion("1.x");
ComparableVersion c2 = new ComparableVersion("1_x");
assertTrue(c1.compareTo(c2) < 0);
}
was (Author: elharo):
This bug appears valid. This test currently fails at head:
{{{}{}}}{{{}{color:#808000}@Test
{color}{color:#80}public void {color}testMNG7701() {{}}}
{{ComparableVersion c1 = {color:#80}new
{color}ComparableVersion({color:#008000}"1.x"{color});}}
{{ComparableVersion c2 = {color:#80}new
{color}ComparableVersion({color:#008000}"1_x"{color});}}
{{assertTrue(c1.compareTo(c2) < {color:#ff}0{color});}}
{{}}}
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7701) Incompatible version sorting changes
[
https://issues.apache.org/jira/browse/MNG-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693475#comment-17693475
]
Elliotte Rusty Harold commented on MNG-7701:
This bug appears valid. This test currently fails at head:
{{{}{}}}{{{}{color:#808000}@Test
{color}{color:#80}public void {color}testMNG7701() {{}}}
{{ComparableVersion c1 = {color:#80}new
{color}ComparableVersion({color:#008000}"1.x"{color});}}
{{ComparableVersion c2 = {color:#80}new
{color}ComparableVersion({color:#008000}"1_x"{color});}}
{{assertTrue(c1.compareTo(c2) < {color:#ff}0{color});}}
{{}}}
> Incompatible version sorting changes
>
>
> Key: MNG-7701
> URL: https://issues.apache.org/jira/browse/MNG-7701
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Major
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> Between 3.8.6 and 3.8.7, the sorting of a variety of version strings has
> changed. This table captures the observed relations:
> ||Input 1||3.8.6||3.8.7||Input 2||
> |{{0.x}}|{{>}}|{{==}}|{{0-x}}|
> |{{1.x}}|{{<}}|{{==}}|{{1-x}}|
> |{{1.x}}|{{<}}|{{>}}|{{1_y}}|
> |{{1.y}}|{{<}}|{{>}}|{{1_x}}|
> |{{1-alpha}}|{{>}}|{{==}}|{{1.alpha}}|
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MNG-7700) Improper canonicalization of versions
[
https://issues.apache.org/jira/browse/MNG-7700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693473#comment-17693473
]
ASF GitHub Bot commented on MNG-7700:
-
michael-o commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117927578
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
I still don't understand why this should not be 0 with `x` as qualifier.
> Improper canonicalization of versions
> -
>
> Key: MNG-7700
> URL: https://issues.apache.org/jira/browse/MNG-7700
> Project: Maven
> Issue Type: Bug
> Components: Core
>Affects Versions: 3.8.7, 3.9.0
>Reporter: David M. Lloyd
>Assignee: Elliotte Rusty Harold
>Priority: Minor
> Fix For: 3.8.x-candidate, 3.9.1-candidate, waiting-for-feedback
>
>
> The canonicalization logic for versions is incorrect.
> Using the method {{ComparableVersion#getCanonical}} as in {{new
> ComparableVersion(input).getCanonical()}}, the following results can be
> observed:
> ||Input||3.8.6 Output||3.8.6 OK?||3.9.0 Output||3.9.0 OK?||
> |{{1}}|{{1}}|yes|{{1}}|yes|
> |{{0.1}}|{{0.1}}|yes|{{0.1}}|yes|
> |{{0-1}}|{{1}}|no|{{1}}|no|
> |{{1.x}}|{{1.x}}|yes|{{1-x}}|maybe*|
> |{{1-x}}|{{1-x}}|yes|{{1-x}}|yes|
> |{{0.x}}|{{0.x}}|yes|{{x}}|no|
> |{{0-x}}|{{x}}|no|{{x}}|no|
> |{{x}}|{{x}}|yes|{{x}}|yes|
> |{{0.rc}}|{{0.rc}}|yes|{{rc}}|no|
> The "OK?" columns indicate whether parsing the canonical version string will
> yield a {{ComparableVersion}} instance that is {{equal}} to one constructed
> from the original input, i.e. it's internally consistent.
> The "maybe*" item indicates that starting with 3.9.0, version `1.x` is now
> considered to be equal to `1-x`. I'm not sure if this is a bug or not, or was
> intentional or not, but it is definitely a change.
> These canonicalizations seem to have gotten less consistent in the move to
> 3.9.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven] michael-o commented on a diff in pull request #1014: [MNG-7700] test some edge cases with leading zeroes
michael-o commented on code in PR #1014:
URL: https://github.com/apache/maven/pull/1014#discussion_r1117927578
##
maven-artifact/src/test/java/org/apache/maven/artifact/versioning/ComparableVersionTest.java:
##
@@ -209,6 +208,26 @@ public void testVersionComparing() {
checkVersionsOrder("2.0.1-xyz", "2.0.1-123");
}
+@Test
+public void testLeadingZeroes() {
+checkVersionsOrder("0.7", "2");
+checkVersionsOrder("0.2", "1.0.7");
+}
+
+@Test
+public void testGetCanonical() {
+// MNG-7700
+newComparable("0.x");
+newComparable("0-x");
+newComparable("0.rc");
+newComparable("0-1");
+
+ComparableVersion version = new ComparableVersion("0.x");
+assertEquals("x", version.getCanonical());
Review Comment:
I still don't understand why this should not be 0 with `x` as qualifier.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #615: [SUREFIRE-2152] Include name of JUnit5 templated-tests in test description
slawekjaranowski commented on PR #615: URL: https://github.com/apache/maven-surefire/pull/615#issuecomment-1445057345 Please check result of ITs - and fix ITs or code according -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #614: [SUREFIRE-2150] upgrade to parent pom 39
slawekjaranowski commented on PR #614: URL: https://github.com/apache/maven-surefire/pull/614#issuecomment-1445056927 I will wait for you - sorry for mess. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] slawekjaranowski commented on pull request #242: Use Maven 3.9.0 on GitHub
slawekjaranowski commented on PR #242: URL: https://github.com/apache/maven-integration-testing/pull/242#issuecomment-1445056606 I would like to go a step forward and also add 4.x After review of #238 I found issue with 4.x Simply we should have a possibility to detect an issue early What do you think? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] olamy commented on pull request #614: [SUREFIRE-2150] upgrade to parent pom 39
olamy commented on PR #614: URL: https://github.com/apache/maven-surefire/pull/614#issuecomment-1445045325 I have stuff already done locally!! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #614: [SUREFIRE-2150] upgrade to parent pom 39
slawekjaranowski commented on PR #614: URL: https://github.com/apache/maven-surefire/pull/614#issuecomment-1445042739 I'm starting work on SUREFIRE-2154, so I want to avoid feature merge conflicts I will do it. Have a rest on beach. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (SUREFIRE-2154) Get rid of ${localRepository} from surefire mojo parameter
[
https://issues.apache.org/jira/browse/SUREFIRE-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Slawomir Jaranowski reassigned SUREFIRE-2154:
-
Assignee: Slawomir Jaranowski
> Get rid of ${localRepository} from surefire mojo parameter
> --
>
> Key: SUREFIRE-2154
> URL: https://issues.apache.org/jira/browse/SUREFIRE-2154
> Project: Maven Surefire
> Issue Type: Improvement
>Reporter: Slawomir Jaranowski
>Assignee: Slawomir Jaranowski
>Priority: Major
> Fix For: 3.0.0-M10
>
>
> It is used in {{org.apache.maven.plugin.surefire.AbstractSurefireMojo}}
> Also in many place in unit and integration test.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] olamy commented on pull request #614: [SUREFIRE-2150] upgrade to parent pom 39
olamy commented on PR #614: URL: https://github.com/apache/maven-surefire/pull/614#issuecomment-1445041553 Oh yes I can finish that. I was on it this morning but had to go to the beach. I will resume work tomorrow -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MRESOLVER-324) Make the BF algorithm as the default option to speed up maven dependency resolution and downloading
[
https://issues.apache.org/jira/browse/MRESOLVER-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17693448#comment-17693448
]
wei cai commented on MRESOLVER-324:
---
[~Chealer] Has been verified by comparing dependency tree output using DF or
BF with thousands of applications in our company before contributing to Maven
community. So far, no downsides found yet. You may try and report if any issues.
> Make the BF algorithm as the default option to speed up maven dependency
> resolution and downloading
> ---
>
> Key: MRESOLVER-324
> URL: https://issues.apache.org/jira/browse/MRESOLVER-324
> Project: Maven Resolver
> Issue Type: Wish
> Components: Resolver
>Affects Versions: 1.10.0
>Reporter: wei cai
>Priority: Major
> Fix For: 1.10.0
>
>
> This is a WISH type Jira :D. So far, Maven 3.9.0 has released a BF algorithm
> which includes changes from below JIRAs along with the DF option (default).
> * MRESOLVER-228
> * MRESOLVER-247
> * MRESOLVER-7
> The BF algorithm solves:
> * Cache missing issue when comes to resolve heavy dependencies with
> different exclusions, it can help speed up dependency resolution especially
> for large scale enterprise level projects.
> * Improve download speed by:
> ** Skip downloading poms for conflict losers.
> ** Download poms in parallel.
> Below is the introduction in
> [https://maven.apache.org/docs/3.9.0/release-notes.html:]
> {noformat}
> Choice of resolver collectors: a new BF collector (with parallel POM
> downloads) has been added along the existing DF one.{noformat}
> The solution is already widely adopted at eBay. You can simply enable it by
> putting below config item into file: ${maven.projectBasedir}/.mvn/maven.config
> {code:java}
> aether.dependencyCollector.impl=bf {code}
> More introduction about this option:
> [https://maven.apache.org/resolver/configuration.html]
> Please try and tells us how much it helps by running:
> {code:java}
> 1. mvn clean install -DskipTests -Dmaven.repo.local=bf
> -Daether.dependencyCollector.impl=bf
> 2. mvn clean install -DskipTests -Dmaven.repo.local=df{code}
> With more feedback collected, we would be able to propose the changes to
> Maven team to make BF as the default.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [maven-surefire] slawekjaranowski commented on pull request #614: [SUREFIRE-2150] upgrade to parent pom 39
slawekjaranowski commented on PR #614: URL: https://github.com/apache/maven-surefire/pull/614#issuecomment-1445040331 @olamy - I can finish it, do you want to work on it -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [maven-integration-testing] slawekjaranowski commented on a diff in pull request #238: [MNG-7661] Fix few build / compiler warnings
slawekjaranowski commented on code in PR #238: URL: https://github.com/apache/maven-integration-testing/pull/238#discussion_r1117893891 ## core-it-support/core-it-javaagent/pom.xml: ## @@ -53,6 +53,17 @@ under the License. shade + + + + *:* + +module-info.class +META-INF/MANIFEST.MF Review Comment: m-jar-p adds items to MANIFEST - see line 40-43 - we need its, so we don't drop MANIFEST we can try https://maven.apache.org/plugins/maven-shade-plugin/examples/resource-transformers.html#ManifestResourceTransformer -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
