Jurrie Overgoor created MRESOLVER-536:
-----------------------------------------
Summary: 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
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. 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
(v8.20.10#820010)
