[
https://issues.apache.org/jira/browse/MRESOLVER-633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17905456#comment-17905456
]
Tamas Cservenak commented on MRESOLVER-633:
-------------------------------------------
Howdy, yes, the "enhanced" LRM implementation is "tracking" the artifact origin
(keyed by repoID). The split repository goes step more, and stores them
physically split (in different directory roots).
As regarding "errors", Resolver is quite simplistic: there are 2 error
classifications: "not found" and "other". See
https://github.com/apache/maven-resolver/blob/master/maven-resolver-spi/src/main/java/org/eclipse/aether/spi/connector/transport/Transporter.java#L37-L51
Handling of these are controlled by
org.eclipse.aether.resolution.ResolutionErrorPolicy class. On Maven "surface"
this is the related option: {{-canf}} or "cache artifact not found" (will store
"not found" errors as you explained, default is true). The other policy "cache
transport errors" is not exposed, is always false (see
org.apache.maven.execution.MavenExecutionRequest#setCacheTransferError and
org.apache.maven.execution.MavenExecutionRequest#setCacheNotFound methods).
And finally, planning and enduring on local repository is wrong, as it can be
seen, the "repositoryId" is the thing that is used to key artifact origins. And
especially if you work for multiple organizations, org A "releases" may be
something complete different the org B "releases". Hence, my own practice is
(the VPN use case as you say), is to have local repository (and whole
settings.xml in fact) per-"realm", per organization as you, as a developer
cannot guarantee that two organizations for sure will not use same
"repositoryID" for two totally different things.
> Clarify caching of unresolvable artifacts in local repository
> -------------------------------------------------------------
>
> Key: MRESOLVER-633
> URL: https://issues.apache.org/jira/browse/MRESOLVER-633
> Project: Maven Resolver
> Issue Type: Improvement
> Components: Resolver
> Reporter: Konrad Windszus
> Priority: Major
> Fix For: 2.0.5
>
>
> A dedicated section in
> https://maven.apache.org/resolver/local-repository.html about local caching
> of unresolvable artifacts would be beneficial.
> IIUC it respects the update policy and all files not found in any remote repo
> are stored as 0 byte artifacts in the local repo.
> It is unclear to me how to deal with edge cases like adding a new repo which
> provides that previously unresolvable release artifact? What do I need to do
> from a consumer perspective to resolve that, if the 0 byte artifact is
> already cached in the local repo...
> Other edge cases include a repository which is only available via a VPN
> connection, which is not always established, so the remote repo may not be
> available at all times and the availability may change without any changes on
> remote repositories on Maven side ({{settings.xml}} or some {{pom.xml}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
