subject:"\[jira\] \[Commented\] \(MRESOLVER\-536\) Skip setting last modified time when FS does not support it"

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-17 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17838169#comment-17838169
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas merged PR #471:
URL: https://github.com/apache/maven-resolver/pull/471




> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837685#comment-17837685
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on code in PR #471:
URL: https://github.com/apache/maven-resolver/pull/471#discussion_r1567225174


##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultPathProcessor.java:
##
@@ -21,22 +21,47 @@
 import javax.inject.Named;
 import javax.inject.Singleton;
 
-import java.io.*;
+import java.io.BufferedInputStream;
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.nio.file.AccessDeniedException;
+import java.nio.file.FileSystemException;
 import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.StandardCopyOption;
+import java.nio.file.attribute.FileTime;
 
 import org.eclipse.aether.spi.io.PathProcessor;
 import org.eclipse.aether.util.FileUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
 
 /**
  * A utility class helping with file-based operations.
  */
 @Singleton
 @Named
 public class DefaultPathProcessor implements PathProcessor {
+private final Logger logger = LoggerFactory.getLogger(getClass());
+
+@Override
+public void setLastModified(Path path, long value) throws IOException {
+try {
+Files.setLastModifiedTime(path, FileTime.fromMillis(value));
+} catch (FileSystemException e) {
+// MRESOLVER-536: Java uses generic FileSystemException for some 
weird cases,
+// but some subclasses like AccessDeniedEx should be re-thrown
+if (e instanceof AccessDeniedException) {
+throw e;
+}
+logger.debug("Failed to set last-modified: {}", path, e);

Review Comment:
   fixed



##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultPathProcessor.java:
##
@@ -21,22 +21,47 @@
 import javax.inject.Named;
 import javax.inject.Singleton;
 
-import java.io.*;
+import java.io.BufferedInputStream;
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.nio.file.AccessDeniedException;
+import java.nio.file.FileSystemException;
 import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.StandardCopyOption;
+import java.nio.file.attribute.FileTime;
 
 import org.eclipse.aether.spi.io.PathProcessor;
 import org.eclipse.aether.util.FileUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
 
 /**
  * A utility class helping with file-based operations.
  */
 @Singleton
 @Named
 public class DefaultPathProcessor implements PathProcessor {
+private final Logger logger = LoggerFactory.getLogger(getClass());
+
+@Override
+public void setLastModified(Path path, long value) throws IOException {
+try {
+Files.setLastModifiedTime(path, FileTime.fromMillis(value));
+} catch (FileSystemException e) {
+// MRESOLVER-536: Java uses generic FileSystemException for some 
weird cases,
+// but some subclasses like AccessDeniedEx should be re-thrown
+if (e instanceof AccessDeniedException) {
+throw e;
+}
+logger.debug("Failed to set last-modified: {}", path, e);

Review Comment:
   fixed





> 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
>Assignee: Tamas Cservenak
>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

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837680#comment-17837680
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

michael-o commented on code in PR #471:
URL: https://github.com/apache/maven-resolver/pull/471#discussion_r1567201048


##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultPathProcessor.java:
##
@@ -21,22 +21,47 @@
 import javax.inject.Named;
 import javax.inject.Singleton;
 
-import java.io.*;
+import java.io.BufferedInputStream;
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.nio.file.AccessDeniedException;
+import java.nio.file.FileSystemException;
 import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.StandardCopyOption;
+import java.nio.file.attribute.FileTime;
 
 import org.eclipse.aether.spi.io.PathProcessor;
 import org.eclipse.aether.util.FileUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
 
 /**
  * A utility class helping with file-based operations.
  */
 @Singleton
 @Named
 public class DefaultPathProcessor implements PathProcessor {
+private final Logger logger = LoggerFactory.getLogger(getClass());
+
+@Override
+public void setLastModified(Path path, long value) throws IOException {
+try {
+Files.setLastModifiedTime(path, FileTime.fromMillis(value));
+} catch (FileSystemException e) {
+// MRESOLVER-536: Java uses generic FileSystemException for some 
weird cases,
+// but some subclasses like AccessDeniedEx should be re-thrown
+if (e instanceof AccessDeniedException) {
+throw e;
+}
+logger.debug("Failed to set last-modified: {}", path, e);

Review Comment:
   `"Failed to set last modified date: {}"`



##
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultPathProcessor.java:
##
@@ -21,22 +21,47 @@
 import javax.inject.Named;
 import javax.inject.Singleton;
 
-import java.io.*;
+import java.io.BufferedInputStream;
+import java.io.BufferedOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
 import java.nio.ByteBuffer;
 import java.nio.charset.StandardCharsets;
+import java.nio.file.AccessDeniedException;
+import java.nio.file.FileSystemException;
 import java.nio.file.Files;
 import java.nio.file.Path;
 import java.nio.file.StandardCopyOption;
+import java.nio.file.attribute.FileTime;
 
 import org.eclipse.aether.spi.io.PathProcessor;
 import org.eclipse.aether.util.FileUtils;
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
 
 /**
  * A utility class helping with file-based operations.
  */
 @Singleton
 @Named
 public class DefaultPathProcessor implements PathProcessor {
+private final Logger logger = LoggerFactory.getLogger(getClass());
+
+@Override
+public void setLastModified(Path path, long value) throws IOException {
+try {
+Files.setLastModifiedTime(path, FileTime.fromMillis(value));
+} catch (FileSystemException e) {
+// MRESOLVER-536: Java uses generic FileSystemException for some 
weird cases,
+// but some subclasses like AccessDeniedEx should be re-thrown
+if (e instanceof AccessDeniedException) {
+throw e;
+}
+logger.debug("Failed to set last-modified: {}", path, e);

Review Comment:
   I think this should be even on trace because it can be very verbose





> 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
>Assignee: Tamas Cservenak
>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

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837626#comment-17837626
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on PR #471:
URL: https://github.com/apache/maven-resolver/pull/471#issuecomment-2058654143

   ping @Jurrie




> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837613#comment-17837613
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas opened a new pull request, #471:
URL: https://github.com/apache/maven-resolver/pull/471

   Do not swallow cases like AccessDeniedEx, and log
   failures. 
   
   This PR builds upon prev PR https://github.com/apache/maven-resolver/pull/468
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-536




> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837604#comment-17837604
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566975705


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   For master I agree, will prep a followup PR that does log





> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837603#comment-17837603
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566975286


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   @rmannibucau As I told to @michael-o , I find this proposal futile, and here 
is why: user @Jurrie spotted this problem ONLY HERE as this was the only one 
spot using method that throws (`Files.setLastModified`). If you look at master 
PR https://github.com/apache/maven-resolver/pull/468 it will show you all the 
places where time mtime is set (as master was ported from `File` to `Path`). So 
all those place will not log anything and are "forgiving" when they try but 
fail to set mtime, and hence, logging it only here makes no sense IMHO. If you 
want, you can make a PR for 1.9.x that sweep changes all `File.setLastModified` 
usages and logs something at TRACE, but I find it useless change (as it never 
logged that so far).





> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837601#comment-17837601
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

rmannibucau commented on code in PR #468:
URL: https://github.com/apache/maven-resolver/pull/468#discussion_r1566966120


##
maven-resolver-spi/src/main/java/org/eclipse/aether/spi/io/PathProcessor.java:
##
@@ -46,6 +48,26 @@ default long lastModified(Path path, long defValue) {
 }
 }
 
+/**
+ * Sets last modified of path in milliseconds, if exists.
+ *
+ * @param path The path, may be {@code null}.
+ * @throws UncheckedIOException If an I/O error occurs.
+ * @return {@code true} if timestamp was successfully set, {@code false} 
otherwise. Reasons of {@code false} may
+ * be multiple, from file not found, to FS not supporting the setting the 
TS.
+ * @since TBD
+ */
+default boolean setLastModified(Path path, long value) {
+try {
+Files.setLastModifiedTime(path, FileTime.fromMillis(value));
+return true;
+} catch (FileSystemException e) {
+return false; // not found Ex belongs here as well

Review Comment:
   guess `AccessDeniedException` must be thrown - agree others can be ignored





> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837600#comment-17837600
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

rmannibucau commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566964022


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   While using path or file is something I don't care debating I think tracing 
there was an error and therefore the lastmodified value is wrong is valuable in 
the log so please log it (`if (!setlastmodified) log.trace()`).





> 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
>Assignee: Tamas Cservenak
>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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837591#comment-17837591
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas closed pull request #467: [MRESOLVER-536] Continue when FS does not 
support 'setLastModifiedTime'
URL: https://github.com/apache/maven-resolver/pull/467




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837594#comment-17837594
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas merged PR #469:
URL: https://github.com/apache/maven-resolver/pull/469




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-16 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837592#comment-17837592
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   Superseded with https://github.com/apache/maven-resolver/pull/468 and 
https://github.com/apache/maven-resolver/pull/469 




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837403#comment-17837403
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

michael-o commented on PR #467:
URL: https://github.com/apache/maven-resolver/pull/467#issuecomment-2057596279

   > I found something like this 
https://robindotnet.wordpress.com/2015/02/27/datetime-stamps-and-azure-file-shares/
   
   Read it. Not very helpful. 




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837369#comment-17837369
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   > @Jurrie are you ok with #468 and #469 ?
   
   I sure am! I'm just glad that this is being picked up as quick as it is. 
You're welcome to close this one @cstamas.




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837365#comment-17837365
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   To be 100% sure I have built this branch and tested it in my cluster. Works! 





> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837350#comment-17837350
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   @Jurrie are you ok with #468 and #469 ?




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837335#comment-17837335
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566025920


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   I disagree, as this is the _only_ place where `Files` is used, while in 
_many other places_ (see master PR, installer, deployer, etc) 
`File.setLastModifiedTime` is used instead. IMHO this PR just "aligns" this one 
cuckoo egg with the rest.





> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837336#comment-17837336
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566025920


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   I disagree, as this is the _only_ place where `Files` is used, while in 
_many other places_ (see master PR, installer, deployer, etc) 
`File.setLastModifiedTime` is used instead. IMHO this PR just "aligns" this one 
cuckoo egg with the rest. The change from `File` to `Path` (and `Files`) 
happened as part of 2.x work...





> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837331#comment-17837331
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

michael-o commented on code in PR #469:
URL: https://github.com/apache/maven-resolver/pull/469#discussion_r1566010743


##
maven-resolver-transport-http/src/main/java/org/eclipse/aether/transport/http/HttpTransporter.java:
##
@@ -691,8 +690,7 @@ public void handle(CloseableHttpResponse response) throws 
IOException, TransferC
 if (lastModifiedHeader != null) {
 Date lastModified = 
DateUtils.parseDate(lastModifiedHeader.getValue());
 if (lastModified != null) {
-Files.setLastModifiedTime(
-task.getDataFile().toPath(), 
FileTime.fromMillis(lastModified.getTime()));
+
task.getDataFile().setLastModified(lastModified.getTime());

Review Comment:
   This will hide the actual exception. I'd move the exception to trace level





> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837330#comment-17837330
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   My proposal https://github.com/apache/maven-resolver/pull/469
   Basically, just "align" and kill this one single place in whole 1.9.x 
codebase that uses `Files` and use `File` method that does not throws.




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837329#comment-17837329
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas opened a new pull request, #469:
URL: https://github.com/apache/maven-resolver/pull/469

   This seems more logical step, simply use File.setLastModified as it does not 
throws, and is used all over the 1.9.x codebase.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-536




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837328#comment-17837328
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   Hm, actually this PR seems good enough for 1.9.x as there is not much to 
backport: this spot is _single use_ of Files.setLastModifiedTime!




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837320#comment-17837320
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   I found something like this 
https://robindotnet.wordpress.com/2015/02/27/datetime-stamps-and-azure-file-shares/




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837316#comment-17837316
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

michael-o commented on PR #467:
URL: https://github.com/apache/maven-resolver/pull/467#issuecomment-2057084821

   > @michael-o see 
[MRESOLVER-536](https://issues.apache.org/jira/browse/MRESOLVER-536), user 
explained there what and why
   
   I did already, but that also means that if a file is created no mtime is set 
at all and reading should fail too.




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837314#comment-17837314
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   Backport from 2.x to 1.x is not straight forward (as 2.x contains changes in 
this area) but is not a problem.




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837313#comment-17837313
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   Sure, will backport it. The release of 1.9.19 is scheduled for "soon":
   
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20fixVersion%20%3D%201.9.19




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837308#comment-17837308
 ] 

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?
   
   The 
[`Files.setLastModifiedTime()`](https://github.com/apache/maven-resolver/pull/467/files#diff-cb82a28d1938522d3e73b0df9a33bf6f80fdb854296bb2020f86fad9c139d22dR696)
 call will throw a `FileSystemException`. This is now 
[caught](https://github.com/apache/maven-resolver/pull/467/files#diff-cb82a28d1938522d3e73b0df9a33bf6f80fdb854296bb2020f86fad9c139d22dR698)
 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
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837307#comment-17837307
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   @michael-o see MRESOLVER-536, user explained there what and why




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837306#comment-17837306
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   I think this one is superseded by 
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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837305#comment-17837305
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

cstamas opened a new pull request, #468:
URL: https://github.com/apache/maven-resolver/pull/468

   Centralize method and apply some common logic.
   
   ---
   
   https://issues.apache.org/jira/browse/MRESOLVER-536




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837296#comment-17837296
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

michael-o commented on PR #467:
URL: https://github.com/apache/maven-resolver/pull/467#issuecomment-2056991223

   I am still confused. When the file is created the mtime is set anyway, no?




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837266#comment-17837266
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   > PR has formatting issues, locally you could `mvn spotless:apply` and 
commit changes, but again, thanks for sharing the important bit.
   
   I force-pushed these changes. Should be green all the way 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
(v8.20.10#820010)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837256#comment-17837256
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   PR has formatting issues, locally you could `mvn spotless:apply` and commit 
changes, but again, thanks for sharing the important bit.




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837253#comment-17837253
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   No, I will handle this. Many thanks for this report!




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837251#comment-17837251
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   > This probably needs to be done in other transports as well Jetty, Java 
HttpClient, etc...
   
   Yes, that could very well be. It's the Java `Files.setLastModifiedTime()` 
call that fails. So if this call is used in other transports, then those will 
also fail.
   
   Is there anything I can do? (I'm not very knowledgeable on the Maven 
Resolver project. In fact: I wouldn't even know if / how to switch to different 
transports )




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread Tamas Cservenak (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837213#comment-17837213
 ] 

Tamas Cservenak commented on MRESOLVER-536:
---

We need to investigate these for all transports, not only Apache as PR does it. 
Maybe just apply same pattern, or pull out this bit into some common 
transport/util.

> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837212#comment-17837212
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

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

   This probably needs to be done in other transports as well Jetty, Java 
HttpClient, etc...




> 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)

[jira] [Commented] (MRESOLVER-536) Skip setting last modified time when FS does not support it

2024-04-15 Thread ASF GitHub Bot (Jira)



[ 
https://issues.apache.org/jira/browse/MRESOLVER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17837113#comment-17837113
 ] 

ASF GitHub Bot commented on MRESOLVER-536:
--

Jurrie opened a new pull request, #467:
URL: https://github.com/apache/maven-resolver/pull/467

   (no comment)




> 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. 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)

39 matches

Mail list logo