Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Split the policies applied in case of data and metadata, allowing greater control of their updates. Still, work "as before" in case of applications that migrate from 1.x resolver (they should receive no behavior change).
The crux of this change is really just to introduce two policies (to co-exist in parallel), but if application using resolver decides to use same policy for both, the original behavior of resolver returns and will seemingly behave as before (ie. like 1.9.x does).
Maven relies on metadata in these cases ONLY:
- resolving maven plugin prefix to maven plugin groupId (G level md)
- resolving snapshot version to timestamped version (V level md)
Resolver OTOH provides one more use case:
- "discovery" of existing versions for given GA (this use case is NOT used in Maven Core) (A level md)
Now, while Maven Core itself does NOT use 3rd use case, some plugins does, most notably the versions-maven-plugin. Today, everyone on Earth use this plugin along with `-U` Maven switch to pick up new stuff from remote repository, but this is total overkill, as it refreshes everything (yes, even the immutable release artifacts!). The `-U` is simply a "must", to make Maven "refresh metadata" (as well, along with all the Artifacts) to pick up new versions on remote. Versions plugin did implement a ["hack" to overcome this limitation](https://github.com/mojohaus/versions/commit/82e2450d8bbd22c3f8cdc06d44c44d618c69e23e), that is still a hack, as it still applies to everything. Proper solution is to have means to express `-U but for metadata only`. This PR makes this possible on resolver side.
Attachments
Issue Links
- is related to
-
-
- Closed
-
- supercedes
-
MRESOLVER-369 Expose configuration for update check manager where to apply policy
-
- Closed
-
- links to