-
Notifications
You must be signed in to change notification settings - Fork 143
[MRESOLVER-369] Introduce update check policy scope #297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This change introduces new configuration: update check policy scope, that limits where (artifact, metadata, both) the update policy is applied. If update policy is not applied, presence/absence decides instead. To achieve "old" behaviour (ie. for use in Maven3), the configuration properties should always be set to "all" in session factory. --- https://issues.apache.org/jira/browse/MRESOLVER-369
...-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/DefaultUpdateCheckManager.java
Outdated
Show resolved
Hide resolved
|
PR is on-hold: testing shows that now when Maven "remembers" that Artifact cannot be downloaded, there is no way to get out of it (-U does not help, as policy is not applied to artifact by default anymore, before it simply went here as -U was "always", and implicitly cleared the error flags as well, so it "fixed" things). IMO, this stems from the fact that policy ALWAYS was simply misused on Maven side (-U), and instead, "force update" on maven side may mean something else, like:
|
|
MRESOLVER-377 is proper fix |
|
Resolve #1044 |
1 similar comment
|
Resolve #1044 |
This change introduces new configuration: update check policy scope, that limits where (artifact, metadata, both) the update policy is applied. If update policy is not applied, presence/absence decides instead.
To achieve "old" behaviour (ie. for use in Maven3), the configuration properties should always be set to "all" in session factory.
https://issues.apache.org/jira/browse/MRESOLVER-369