Skip to content
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

Closed
cstamas opened this issue May 7, 2023 · 9 comments
Closed

Adopt MIMA #423

cstamas opened this issue May 7, 2023 · 9 comments
Assignees
Labels
Milestone

Comments

@cstamas
Copy link
Contributor

cstamas commented May 7, 2023

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
Copy link
Contributor Author

cstamas commented May 7, 2023

@tonit
Copy link
Member

tonit commented May 7, 2023

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
Copy link
Contributor Author

cstamas commented May 7, 2023

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 grgrzybek added the type: improvement Improvement label May 7, 2023
@grgrzybek grgrzybek added this to the 2.7.0 milestone May 7, 2023
@grgrzybek
Copy link
Member

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
Copy link
Contributor Author

cstamas commented May 7, 2023

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

@grgrzybek grgrzybek self-assigned this May 9, 2023
cstamas added a commit to maveniverse/mima that referenced this issue Jun 15, 2023
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
@cstamas
Copy link
Contributor Author

cstamas commented Jun 15, 2023

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

@grgrzybek
Copy link
Member

Thanks - it's still on my radar ;)

@grgrzybek
Copy link
Member

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
Copy link
Member

splatch commented Nov 27, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants