[
https://issues.apache.org/jira/browse/MRESOLVER-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17773821#comment-17773821
]
Tamas Cservenak commented on MRESOLVER-372:
-------------------------------------------
This is very cool! Thank you for your investigation, time and "thought
experiments", i really like them.
Yes, snapshot normalization (the thing that copies the latest downloaded
TIMESTAMPED snapshot to -SNAPSHOT in local repository) is probably the culprit,
and IF maven local repository could have immutable files (like releases are),
it would be the simplest. Ideally, am keen to wild experiments even to make
local repo CAS-like (content addressable storage), but to achieve that, we must
"herd" all the code (authors) to strictly adhere and use Resolver APIs to
figure out where the artifact belonging file is, and we still struggle with
ancient codebases running in Maven...
I think "maven resolver dealing with which timestamped snapshot to use" is
doable even without depending on local clock, but I see a bigger problem "all
the rest of the world", that as I said, have copy-pasted code and assume local
repo layout and so on...
A big :thumbsup: for this comment.
> Download fails if file is currently in use under windows
> --------------------------------------------------------
>
> Key: MRESOLVER-372
> URL: https://issues.apache.org/jira/browse/MRESOLVER-372
> Project: Maven Resolver
> Issue Type: Bug
> Reporter: Christoph Läubrich
> Priority: Major
>
> With the new file-locking in maven-resolver there is a problem under windows
> if the file is currently used by another process (this can for example happen
> in an IDE ...) and resolver likes to move the file:
>
> {code:java}
> Caused by: java.nio.file.AccessDeniedException:
> xxx-SNAPSHOT.jar.15463549870494779429.tmp -> xxxx-SNAPSHOT.jar
> at
> java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:89)
> at
> java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
> at java.base/sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:317)
> at
> java.base/sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:293)
> at java.base/java.nio.file.Files.move(Files.java:1432)
> at org.eclipse.aether.util.FileUtils$2.move(FileUtils.java:108)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:96)
> at
> org.eclipse.aether.internal.impl.DefaultFileProcessor.copy(DefaultFileProcessor.java:88)
> at
> org.eclipse.aether.internal.impl.DefaultArtifactResolver.getFile(DefaultArtifactResolver.java:490)
> ... 30 more{code}
>
> My suggestion would be that resolver simply uses the temp file if it can't be
> moved to final location and marks it as delete on exit. Even though this is
> not optimal, it at least ensures the the build does not fail to the cost that
> next time the file needs to be downloaded again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
