-
Notifications
You must be signed in to change notification settings - Fork 57
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
Adopt MIMA #423
Comments
Adoption of MIMA should solve: |
Sounds cool! Originally I thought of aether doing exactly this. |
Aether alone as we know is not enough. Hence, anything that Aether would provide would be (and is) incomplete (as one have to "tie in" things like models and missing components, mostly from maven-resolver-provider). But even then, things are incomplete, as settings.xml discovery, potential decryption of it and many more logic (present in Maven) is not yet there, hence more code needed. All the projects using Resolver I saw is duplicating all these efforts (and in the process doing questionable decisions). MiMa is just a "glue" that brings these things together, and it only helps you to grab reference to repoSystem and session configured as you want. After it, it does NOT interfere in any way. Still, since Resolver 1.9.x a repoSystem shutdown is must (and in 1.10.x session close is coming as well) so it offers simple means (Closeable) to handle and clean up Aether properly, taking all of these burden off from you. Due incompleteness above, we plan to deprecate Guice modules as well, but ServiceLocator is on our eyesight since long time, as it's presence forces Resolver components to be coded in "good ol Plexus DI way", so components must have default ctor, no ctor injection possible, and many circumvention is needed at source level in Resolver itself to make it work, So in 2023 please do NOT touch SL anymore, as MIMA "standalone-static" provides full (and much better) replacement for it with all the whistle and bells. |
Thanks @cstamas, I'll have a look, because it's about time to move away from aether. Give me some time to check the impact in things like Pax Web and Karaf (karaf-maven-plugin uses pax-url-aether underneath). |
One remark: when you are using MIMA, all these (from "proper" resolver) applies:
|
Changes: * distinguish and add overrides for user and global settings file * add possibility to add (effective) `Settings` override (overrides all discovery and everything), this might come good forhttps://github.com/ops4j/org.ops4j.pax.url/issues/423 as well (they also prepare "effective" settings and pass wherever needed) -- one trick: as MIMA does NOT depend on Maven internals, it is `Object` to keep deps out * settings builder should receive system/user properties * implement proper profile activation (using CWD as "project home"), may add override for this as well * enable "repository override" (by ID), fixes #13
FTR https://github.com/maveniverse/mima/releases/tag/release-2.3.0 is out w/ new features |
Thanks - it's still on my radar ;) |
Fixed with #417 (I did some direct usage of |
I've played a bit with MIMA in another project and got it working for basic use case of scanning remote repositories for snapshots/releases. Beyond supplying initial list of repositories and storage path I didn't have to worry much about all other setup tasks needed to get resolver running. From usage point of view it is quite ok. |
I'd like to propose for this library to adopt MIMA and delegate "maven like" behavior to it. Current landscape of libraries and apps using Aether/Resolver (without Maven but "as in Maven") is very rough, and almost all the apps retry to do the same thing: mimic Maven, and usually they do it wrongly. MIMA offers solution to this.
https://github.com/maveniverse/mima/tree/main
MIMA is Java 8 library, makes use of latest Resolver versions and makes available all the latest features of it (remote repository filtering, local repository locking, new transport that cuts request count in half and many more).
Basic usage in short: make MIMA
context
module compile time dependency and use it like this:To make it work, add any MIMA
runtime
as runtime-only dependencies you need (you don't need them compile time).There are 3 runtimes:
Naturally, you only need one "standalone-*" runtime, no need for both, while "embedded-maven" may be always present, as it does not stir any water (does not have any transitive dependencies and "activates" itself ONLY when inside Maven).
As Resolver (not MIMA) uses SLF4J for logging, you also need to provide a back-end for it at runtime.
By using that pattern above, your code is transportable between all use cases and is simply oblivious where it runs: it will run transparently inside or outside of Maven.
PS: to get rid of build-time warnings of latest maven-plugin-plugin, best is to exclude "standalone-" runtimes when your library using MIMA is used within Mojo, as otherwise maven-plugin-plugin will detect maven artifacts in "wrong scope" (not in provided scope).
The text was updated successfully, but these errors were encountered: