Incorporate/reuse MIMA CLI

[cstamas]

Is your feature request related to a problem? Please describe.
While doing JBang contributions it struck me how easy is to create CLI (and REPL). Hence, MIMA got a small CLI tool as well with "resolver commands" that are IMHO very handy (like "total commander" for Maven reposes).

Describe the solution you'd like
Ideally, I'd like JBang to somehow reuse (to prevent copy+paste and maintenance/sync burden) MIMA CLI, and have JBang "resolver resort (or section)" of commands. Everything is here (sans MASE). With proper code changes/reorganization on MIMA side (as currently there is one single monolithic CLI module) and maybe some "adapting glue" on JBang side, this could work.

Describe alternatives you've considered
To have MIMA "compete" with JBang? 😄 I would really like to come up with some solution that benefits both parties (full reuse), and requires least effort once done (ie. just update mima dep versions and get new commands, etc).

Additional context
As MIMA CLI was born during my initial JBang contribution, is not yet quite documented, but you can see it here:
https://github.com/maveniverse/mima/tree/main/cli/src/main/java/eu/maveniverse/maven/mima/cli

It offers some trivial commands like "deploy" (to remote repo), "install" (to local repo), "resolve" and "graph", most of the usual stuff you expect with maven. But, the more interesting bits are following commands:

• classpath: resolve GAV to local repo and print out classpath (for copy-paste)
• verify: make sure that GAV and SHA1 you provide matches with remote (local artifact is untampered)
• exists: just that, check existence in remote repo (context: this command as trivial as it looks, makes sure when it returns "true" that artifact is there and is reachable... use case for it is some sort of automation, when there is "bad reputation" sync to Central involved. For example ASF release process is PITA, as once you close/release staging repository, you sit there waiting for "sync to happen" to continue the release process. Using this tool, by supplying the list of "released artifacts" and checking on Central, the workflow could be automated)
• search: relies on unreliable search.maven.org webservice (obviously works for central only)
• identify: you give a SHA1 and it tells you what it is, relies on unreliable search.maven.org webservice (obviously works for central only)
• list: lists G (artifactIds in G), G:A (versions in GA) or G:A:V (artifacts available under GAV, the POM, JAR, classifiers within one GAV). The G and GAV listing is "best effort" (jsoup HTML parsing, implemented for Central and Nx2), but GA list is reliable as it uses Maven Repository Metadata.
• and there is one interesting set of commands: repl + record + deploy recorded. What this does is that it "records" any resolver touched artifacts (ie. after you start recording, it collects all you resolved, even several times), and at the end you invoke deployRecorded. This reimplements the venerable https://github.com/simpligility/maven-repository-tools tool in much friendlier way, helps you to deploy artifacts (and their transitive hull) for example in air tight environment, or so.

Note: MASE is "maven search" (yeah, you guessed it 😄 ) and have 3 backends, one of them is "maven-indexer". Hence, most MASE related commands (like identify, search) CAN work against custom index, assuming one provides up to date indexes to any repository.

The beauty is that in MIMA CLI all you need is to refer to serverId, and MIMA collects all the info (like auth), hence no need to explicitly set/enter usernames and passwords like is for example in case of maven-repository-tools. If you have your settings.xml set up for your env (and hopefully you do), you are free to go to move your artifacts around...

Our real life use case at work is this: in a project we mix java and groovy sources (something I would not do today, but meh), and to make it happen, we need to use eclipse-groovy compiler with maven-compiler-plugin (instead of javac). But alas, while Groovy itself is published to Central, the eclipse-groovy compiler is not published there (is only available from AF service, but even there is some mixup and "dirty" reposes, see groovy/groovy-eclipse#1359). To not proxy that repo, we actually "provision" the eclipse compiler artifacts and deploy them to our "thirdparty-releases" hosted repository (while rest of Groovy comes from Central proxy).

Basically, this idea needs work:

• figure out how to reorganize MIMA CLI to make it reusable (probably for start to split the monolith CLI)
• figure out how to make JBang pick up those commands and publish them under "resolver" or similar group. Would probably need some "glue" or adapter-like stuff.
• make it happen 😄

Some demos:

• list https://asciinema.org/a/Kfdbou9joYS7chTcfFWXVC46Z
• deployRecorded https://asciinema.org/a/0n8mUpw7im902VbjCam7cbPNN

[maxandersen]

Cool.

Some of the commands jbang already has jbang info classpath for example.

Verify I think would be just a mode when resolving but those are details.

Jbang gavsearch@jbangdev does searching.

But all good for exploring better options/coordinations.

Not sure if jbang would use the mima cli directly ? Would it not be simpler best to continue to use as library and something like sub commands like the plugin feature pr could be use to combine the best of all the worlds?

would be fun with a brainstorming session on it before the break to have something to iterate on.

[cstamas]

Re integration: def not using mima cli directly, but I think some refactoring will be needed on MIMA CLI side (as it is currently a "monolithic JAR"), explode it into 2-3 JARs maybe and JBang should just pick it up as plain dependency and somehow "mount" the commands under "resolver" group? Unsure, am newbie with picocli 😄

💯 for brainstorming

[cstamas]

Just for fun, @gnodet came up with this and it works just nice:

///usr/bin/env jbang "$0" "$@" ; exit $?
//DEPS eu.maveniverse.maven.mima:cli:2.4.4

class Cli {
    public static void main(String... args) {
        eu.maveniverse.maven.mima.cli.Main.main(args);
    }
}

[quintesse]

and it works just nice:

Btw you can also simply do jbang eu.maveniverse.maven.mima:cli:2.4.4 (or :LATEST of course).

And you can easily create an alias for that or install it as a local command. No need for the small wrapper script.

Btw, that JAR seems compiled for Java 11, is the rest of MIMA compiled with Java 11 as well? Asking because with JBang we're still supporting Java 8.

Edit: just checked, JBang still seems to work fine on 8, so it must be just the "cli" artifact.

[cstamas]

Maven Indexer is 11, hence cli is as well. Mima and resolver are java8