[ https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17837596#comment-17837596 ]
ASF GitHub Bot commented on MRESOLVER-536: ------------------------------------------ cstamas merged PR #468: URL: https://github.com/apache/maven-resolver/pull/468 > 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 (v8.20.10#820010)