ASF GitHub Bot commented on MRESOLVER-536:

Jurrie commented on PR #467:
URL: https://github.com/apache/maven-resolver/pull/467#issuecomment-2057041926

   > I am still confused. When the file is created the mtime is set anyway, no?
 call will throw a `FileSystemException`. This is now 
 and the process continues. Previously the exception was _not_ caught and 
bubbled up, causing Maven to spit out the error and stop execution.
   > I think this one is superseded by #468
   Seems like it, as the exception is caught there as well. I was wondering if 
this could be merged in to Maven Resolver 1.9.x? I would really like to have 
this in general Maven as soon as possible. I don't like running my own 
Frankenstein version of Maven (self-compiled version of Maven Resolver), which 
I'm doing now.

> Skip setting last modified time when FS does not support it
> -----------------------------------------------------------
>                 Key: MRESOLVER-536
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-536
>             Project: Maven Resolver
>          Issue Type: Improvement
>          Components: Resolver
>    Affects Versions: 1.9.18
>            Reporter: Jurrie Overgoor
>            Priority: Major
>             Fix For: 2.0.0, 1.9.19, 2.0.0-alpha-11
>         Attachments: Stacktrace.txt
> When Maven resolver downloads a file and writes it to disk, it tries to set 
> the last modified time on it. There are filesystems that do not support the 
> "set last modified time" operation. In that case the operation will fail, and 
> the Maven build will error out with a {{FileSystemException}}. Attached is 
> (the last part of) such a stack track trace.
> I encountered such a file system when running in a Kubernetes (Openshift 
> actually, but that's Kubernetes based) cloud setup. I mapped the {{~/.m2}} 
> directory to a Persistent Volume Claim so that files downloaded in one build 
> are retained in the next build. I explicitly set the access mode to 
> ReadWriteMany (a.k.a. RWX, a.k.a. Shared Access) so that multiple build nodes 
> can use the same PVC. The PVC is provisioned by a [`file.csi.azure.com` 
> provisioner|https://learn.microsoft.com/en-us/azure/aks/azure-files-csi]. And 
> that translates to a file system that does not support setting the last 
> modified time on a file. Thus the call to 
> {{java.nio.file.Files.setLastModifiedTime(Path, FileTime)}} in 
> {{org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse)org.eclipse.aether.transport.http.HttpTransporter.EntityGetter.handle(CloseableHttpResponse)}}
>  comes crashing down.
> There is no good way to query if the FS supports the call. So I resorted to 
> wrapping the call in a `try .. catch` block. This seems to work. Maven 
> downloads dependencies again, and my build progresses.

This message was sent by Atlassian Jira

Reply via email to