[
https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610002#comment-17610002
]
ASF GitHub Bot commented on MRESOLVER-273:
------------------------------------------
michael-o commented on code in PR #194:
URL: https://github.com/apache/maven-resolver/pull/194#discussion_r981138519
##########
maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/synccontext/named/NameMapper.java:
##########
@@ -30,6 +30,14 @@
*/
public interface NameMapper
{
+ /**
+ * Returns {@code true} if lock names returned by this lock name mapper
are file system friendly, can be used
+ * as file names and paths.
+ *
+ * @since TBD
+ */
+ boolean isFileSystemFriendly();
Review Comment:
I wonder whether we we would have other boolean flags and that could turn
rather into a `NameMapperFeature` enum?! with `boolean
hasFeature(NameMapperFeature)`?
> 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)
