[
https://issues.apache.org/jira/browse/MRESOLVER-700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17944294#comment-17944294
]
ASF GitHub Bot commented on MRESOLVER-700:
------------------------------------------
cstamas commented on code in PR #685:
URL: https://github.com/apache/maven-resolver/pull/685#discussion_r2041726425
##########
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:
Yes, for "generic" (existing) file we throw NoTransporterException that is
"expected" by transport provider, and will make it to move to next factory, and
finally will report error like "no transport for repo X". But, in case of
"bundle:" transport, the file MUST exists and must be ZIP file and we have to
be able to open it... if any of these fail, we do "hard failure" that will fail
maven completely, as it is most probably user error, like bad ZIP file path or
ZIP is simply not there...
> 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)
