[
https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17609249#comment-17609249
]
ASF GitHub Bot commented on MRESOLVER-273:
------------------------------------------
cstamas commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r979461033
##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/BasedirNameMapper.java:
##########
@@ -0,0 +1,84 @@
+package org.eclipse.aether.internal.impl.synccontext.named;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+import java.io.File;
+import java.io.IOException;
+import java.io.UncheckedIOException;
+import java.nio.file.Path;
+import java.util.Collection;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.ConcurrentMap;
+import java.util.stream.Collectors;
+
+import org.eclipse.aether.RepositorySystemSession;
+import org.eclipse.aether.artifact.Artifact;
+import org.eclipse.aether.metadata.Metadata;
+import org.eclipse.aether.named.support.FileSystemFriendly;
+import org.eclipse.aether.util.ConfigUtils;
+
+import static java.util.Objects.requireNonNull;
+
+/**
+ * Wrapping {@link NameMapper} class that is {@link FileSystemFriendly}: it
wraps another
+ * {@link FileSystemFriendlyNameMapper} and resolves the resulting "file
system friendly" names against local
+ * repository basedir.
+ *
+ * @since TBD
+ */
+public class BasedirNameMapper implements FileSystemFriendlyNameMapper
+{
+ private static final String CONFIG_PROP_LOCKS_DIR_NAME =
"aether.syncContext.named.basedir.locksDirName";
+
+ private final FileSystemFriendlyNameMapper delegate;
+
+ private final ConcurrentMap<String, Path> basedirs;
+
+ public BasedirNameMapper( final FileSystemFriendlyNameMapper delegate )
+ {
+ this.delegate = requireNonNull( delegate );
+ this.basedirs = new ConcurrentHashMap<>();
+ }
+
+ @Override
+ public Collection<String> nameLocks( final RepositorySystemSession session,
+ final Collection<? extends Artifact>
artifacts,
+ final Collection<? extends Metadata>
metadatas )
+ {
+ final String locksDirName = ConfigUtils.getString( session, ".locks",
CONFIG_PROP_LOCKS_DIR_NAME );
+ final File localRepositoryBasedir =
session.getLocalRepository().getBasedir();
+ // here we abuse concurrent hash map to make sure costly
getCanonicalFile is invoked only once
+ final Path basedir = basedirs.computeIfAbsent(
localRepositoryBasedir.getPath(), k ->
+ {
+ try
+ {
+ return new File( localRepositoryBasedir, locksDirName
).getCanonicalFile().toPath();
Review Comment:
Well, if you look, I just _moved_ the code from FileGAVNameMapper (see
master), separated it in two, the BasedirNameMapper and FileGAVNameMapper... so
here you question the old code :smile:
If that's not the case, let's dissect it, but I'd not stuck on old code....
(as we can improve it anyway post this PR)
> Create more compact File locking layout/mapper
> ----------------------------------------------
>
> Key: MRESOLVER-273
> URL: https://issues.apache.org/jira/browse/MRESOLVER-273
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Tamás Cservenák
> Assignee: Tamás Cservenák
> Priority: Major
> Fix For: resolver-next
>
>
> Current FileGAVNameMapper "mimics" loosely local reposiory layout, uses long
> paths, hence (relatively) big strings etc.
> More compact layout would be just to hash strings like "a:G:A:V" and
> "m:G[:A[:V]]" for artifacts and metadata instead, and create 2 level deep
> hashed storage.
> Problem with "loose" layout is that they do end up as files in OS, while
> these would be much shorter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
