Adopt MIMA

[cstamas]

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:

        ContextOverrides overrides = ... build it using ContextOverrides.Builder
        try (Context context = Runtimes.INSTANCE.getRuntime().create(overrides)) {
          // use resolver: context carries resolverSystem, resolverSystemSession, remoteRepositories
        }

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:

• embedded-maven - used when running "embedded"
• standalone-sisu - used when running "standalone", uses Eclipse Sisu/Guice DI (as in Maven)
• standalone-static - used when running "standalone", replacement for deprecated ServiceLocator

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).

[cstamas]

Adoption of MIMA should solve:

• https://github.com/ops4j/org.ops4j.pax.url/issues/397
• https://github.com/ops4j/org.ops4j.pax.url/issues/417

[tonit]

Sounds cool! Originally I thought of aether doing exactly this. If MiMa (love the name Mini Maven) is the thing to go for in 2023 then you are probably right. Thanks, @cstamas ! Will look into this if no one else picks this up earlier.

[cstamas]

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.

[grgrzybek]

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).

[cstamas]

One remark: when you are using MIMA, all these (from "proper" resolver) applies:

• "be a good citizen": https://maven.apache.org/resolver/api-compatibility.html
• you have access to all these (via "user properties"): https://maven.apache.org/resolver/configuration.html
• MiMa intentionally shields you from Maven Models, so you should NOT tamper with Settings etc. If you want to mangle them (ie, in a test), you can still create own Settings, store it on disk and point MiMa at it.

[cstamas]

FTR https://github.com/maveniverse/mima/releases/tag/release-2.3.0 is out w/ new features

[grgrzybek]

Thanks - it's still on my radar ;)

[grgrzybek]

Fixed with #417 (I did some direct usage of org.ops4j.pax.url.mvn.internal.PaxRepositorySystemSupplier, but I also use as much as I could (I was in quite a hurry) from MiMa).

[splatch]

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.