[Feature Request] Restore CLI Interface for integrating with other tools

[blorente]

Problem

At Twitter, we are migrating from the pants build tool to Bazel. As part of that effort, we want to validate that the JVM artifacts we create with Bazel are similar enough to the ones previously created with Pants. For our intents and purposes, we have decided that bidirectional binary compatibility is a good criteria to validate artifacts.

MiMa is the best and most mature tool for this purpose. However, it currently only ships as an SBT plugin, which makes it impossible for us to use.

Possible Solution

We have prototyped replicating the CLI described here, and that works extremely well for our use case. This prototype was made by calling MiMaLib.collectProblems with the appropriate files. However, MiMaLib is protected, so we can't really rely on this prototype.

It looks like the CLI was removed some time ago, but I haven't been able to find the exact commit that did it due to the splitting of project/Build.scala that happened sometime last year.

Would you be open to contributions adding back that CLI? Are there other ways to use MiMa as anything other than an SBT plugin?

Ideally, we'd be able to use MiMa as a library and manipulate the problem list, but just being able to call it as a CLI application would be great.

[SethTisue]

The CLI removal PR was #208

I wouldn't be excited about the CLI coming back (though how @dwijnand feels is more important), but MiMaLib definitely ought to work well enough to allow other build tools to integrate it — there's no question about that. If more stuff needs to be made public to make that happen, or other tweaks are needed, I don't think there will be resistance. #547 is an example where Dale made a fix in that area recently, to help a build tool plugin maintainer (https://github.com/kelnos/mima-maven-plugin).

[dwijnand]

A few weeks ago I wanted to build a little CLI for myself, and see if I could native-image compile it for speedy runs. So I have an interest in this being becoming available.

But I'm thinking it would be easier to define and maintain a stable programmatic API, allowing for multiple CLIs, rather than a CLI API. (Possibly because of the vast amount of more time spent on programmatic APIs.)

So what would that look like?

We have prototyped replicating the CLI described here, and that works extremely well for our use case. This prototype was made by calling MiMaLib.collectProblems with the appropriate files. However, MiMaLib is protected, so we can't really rely on this prototype.

What do you mean MiMaLib is protected? Perhaps this is a language difference, do you mean that it's an issue that it's final? Because other than that it's public and so is its collectProblems, meaning that new MiMaLib(cp).collectProblems(v1, v2) is already available.

If that works for you then the only thing I'd want to do is record that in my unofficial public API docs https://github.com/lightbend/mima/blob/8ce114ab5c176d043f7f5058568a74e4d019dd77/project/MimaSettings.scala#L21.

[blorente]

What do you mean MiMaLib is protected?

Turns out I was trying to use it wrong, my inexperience with Scala came to bite me. You're right, I was able to use MiMaLib as a library to build my own binary, and it was a great experience!

Thanks for the help, I'd be happy to add a PR to move MiMaLib from https://github.com/lightbend/mima/blob/8ce114ab5c176d043f7f5058568a74e4d019dd77/project/MimaSettings.scala#L33 to https://github.com/lightbend/mima/blob/8ce114ab5c176d043f7f5058568a74e4d019dd77/project/MimaSettings.scala#L21 if you'd like.

Sorry for my mistake, and thanks for the help!