[
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jurrie Overgoor updated MRESOLVER-536:
--------------------------------------
Description:
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.
was:
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.
> 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
> 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
(v8.20.10#820010)
