This message was deleted.

I'm always open to PRs 🙂 But can you clarify the intent? At first glance it seems strange to expose different classes variants to consumers, when the goal of mrjars is to have a single output for multiple consumers.

I want downstream Java 11 (say) source-sets in the multi-project build to be able to compile against the Java 11 classes and not against the vanilla Java 8 classes. This means that although there is only one variant of the jar which leans on Multi-Release we have multiple variants of the classes directory for the different JVM versions that use regular Gradle variant matching. My main concern here is fixing the compilation of module-info.java in multi-project builds… but in principle there could be other purposes too.

I am not sure it makes sense. When you compile against a library, only the ABI should be considered. And the ABI of different modules should be exactly the same.

The ABI includes the module-info.class though…

if I recall properly

module-info

is only supported within a jar, and it should be in the mrjar under

META-INF/versions/whatever

Library authors don’t get to make choices… we suffer under the weight of our users choices 😞

that's because it defines the unit of what is visible externally. Otherwise potentially you can have classes on classpath in the same package as one in the module...