[
https://issues.apache.org/jira/browse/MRESOLVER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605795#comment-17605795
]
ASF GitHub Bot commented on MRESOLVER-273:
------------------------------------------
cstamas opened a new pull request, #194:
URL: https://github.com/apache/maven-resolver/pull/194
Create more compact FS NameMapper. Also, clean up existing ones and reduce
clutter and mess.
High level changes:
* Introduce StringDigestUtil for String hashing (cleanup the mess of
digest/checksum mixup, deprecate and make unused SimpleDigest)
* Introduce HashingNameMapper (implements the "more compact" name mapper)
* Cleanup and simplify existing NameMapper implementations
* Introduce providers for "user facing" configuration names, as those are
usually combination of existing NameMappers (like one wrapping other, etc).
Hence, to keep things simple, no NameMapper is component anymore but dedicated
providers are constructing them. No user facing change happens by this, as
mapper names remains same.
---
https://issues.apache.org/jira/browse/MRESOLVER-273
> 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
> Reporter: 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)
