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

ASF GitHub Bot commented on MRESOLVER-700:
------------------------------------------

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


##########
maven-resolver-transport-file/src/main/java/org/eclipse/aether/transport/file/FileTransporterFactory.java:
##########
@@ -66,28 +65,61 @@ public FileTransporterFactory setPriority(float priority) {
         return this;
     }
 
+    /**
+     * Creates new instance of {@link FileTransporter}.
+     *
+     * @param session The session.
+     * @param repository The remote repository.
+     */
     @Override
     public Transporter newInstance(RepositorySystemSession session, 
RemoteRepository repository)
             throws NoTransporterException {
         requireNonNull(session, "session cannot be null");
         requireNonNull(repository, "repository cannot be null");
 
-        // special case in file transport: to support custom FS providers 
(like JIMFS), we cannot
-        // cover "all possible protocols" to throw NoTransporterEx, but we 
rely on FS rejecting the URI
-        FileTransporter.FileOp fileOp = FileTransporter.FileOp.COPY;
         String repositoryUrl = repository.getUrl();
-        if (repositoryUrl.startsWith("symlink+")) {
-            fileOp = FileTransporter.FileOp.SYMLINK;
-            repositoryUrl = repositoryUrl.substring("symlink+".length());
-        } else if (repositoryUrl.startsWith("hardlink+")) {
-            fileOp = FileTransporter.FileOp.HARDLINK;
-            repositoryUrl = repositoryUrl.substring("hardlink+".length());
-        }
-        try {
-            return new FileTransporter(
-                    
Paths.get(RepositoryUriUtils.toUri(repositoryUrl)).toAbsolutePath(), fileOp);
-        } catch (FileSystemNotFoundException | IllegalArgumentException e) {
-            throw new NoTransporterException(repository, e);
+        if (repositoryUrl.startsWith("bundle:")) {
+            try {
+                repositoryUrl = repositoryUrl.substring("bundle:".length());
+                URI bundlePath = URI.create("jar:"
+                        + Paths.get(RepositoryUriUtils.toUri(repositoryUrl))
+                                .toAbsolutePath()
+                                .toUri()
+                                .toASCIIString());
+                Map<String, String> env = new HashMap<>();
+                FileSystem fileSystem = FileSystems.newFileSystem(bundlePath, 
env);
+                return new FileTransporter(
+                        fileSystem,
+                        true,
+                        false,
+                        fileSystem.getPath(fileSystem.getSeparator()),
+                        FileTransporter.WriteOp.COPY);
+            } catch (IOException e) {
+                throw new UncheckedIOException(e); // hard failure; most 
probably user error (ie wrong path or perm)

Review Comment:
   This is again along the lines of this:
   * reading bundle: URL must point to existing ZIP file and we read only
   * creating bundle: URL (once we do it) will have to point to non existing 
ZIP file we create
   
   In both cases, we must ensure these are true, and do "hard fail". In case of 
"file" (and if you look at any other transport factory), the 
NoTransportException is more like factory stating "nah, I cannot handle this 
URL, go and try with another or report error"





> Bundle transport
> ----------------
>
>                 Key: MRESOLVER-700
>                 URL: https://issues.apache.org/jira/browse/MRESOLVER-700
>             Project: Maven Resolver
>          Issue Type: Task
>            Reporter: Tamas Cservenak
>            Assignee: Tamas Cservenak
>            Priority: Major
>             Fix For: 2.0.9
>
>
> It is becoming more and more common that various services require "zipped up 
> bundle" (using remote repository layout) of things like releases. As 
> experiment shows, these can be used as "remote repositories" as well (with 
> existing classpath transport). What if we have a dedicated transport? As 
> before, we defined remote repository that point to a staging repo, but have 
> it point to a ZIP file (either local or remote).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to