[
https://issues.apache.org/jira/browse/MRESOLVER-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17843367#comment-17843367
]
Tamas Cservenak commented on MRESOLVER-555:
-------------------------------------------
This is wrong. This cannot happen in all cases...
Simply put, Resolver has no notion of "wandering artifacts", but it does try
hard to enforce error policy ("cache 404").
I think the proper solution would be to be able to assign
{{org.eclipse.aether.resolution.ResolutionErrorPolicy}} not only session-wide,
but to a RemoteRepository (code change in Resolver but also code change in
Maven). As then, solution would be:
* super POM states "do not cache 404 for Central", but
* do cache as today (per session level)
Also with this exposed, any organization could set/configure whatever setup
they have, like "by the book" setup of staging suite that ends up in releases
repo...
Ideas welcome.
> Existence check should lax the repository update policy
> -------------------------------------------------------
>
> Key: MRESOLVER-555
> URL: https://issues.apache.org/jira/browse/MRESOLVER-555
> Project: Maven Resolver
> Issue Type: Bug
> Components: Resolver
> Reporter: Tamas Cservenak
> Priority: Major
> Fix For: 2.0.0, 2.0.0-beta-1
>
>
> Maybe only when update policy is "never".
> Order of events:
> * attempt a build with not-yet-released-artifact (for example resolver in
> maven)
> * as it is not in central, build will fail, and central URL will be "cached"
> as 404 for given artifact
> * fix, rinse, repeat, add staging repository, rebuild
> * build will pass ok, as staging repository will have the artifact, it is
> cached to local repository (from staging repository)
> * later, staging repository is dropped, release promoted to central.
> * rebuild: here, Resolver will nag that "artifact is present but not
> available", which is true: it was cached from staging repository
> * it will go try to see is it available in central (existence check), but:
> central has 404 cached (see step 1), and in this case update policy is being
> obeyed, that is "never"
> * due "never" update policy existence check will fail, and build will fail
> Now, IMO, for "existence check" Resolver should lax the policy ONLY if it is
> "never" maybe? As from this situation only escape route is build with -U that
> will reset local repository state and build will pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
