On 21.11.2017 09:17, Cédric Champeau wrote:
I agree with Leonard. It's a bit premature to use Automatic-Module-Name, because we're simply not "modularization-ready". And I agree that the first step should be to move away from `groovy-all.jar`, which is possible now that groovy and groovy-all are both relocating packages the same way, so the all version can become a pure dependency artifact.
Fatjars can´t export multiple modules, yes, but that is because they are one module only. So they are compatible, you just cannot replace the fatjar later with multiple jars and let them share names. But why not call the fatjar different then?
And because groovy.jar and groovy-all.jar cannot coexist in the module world, as cannot groovy-all.jar and the actual module jars (because of what they export), what would be the first step into the module world, when you are actually not ready yet? You make a fat jar.
So in my view it will either take a long time till we haven an even cleanly defined module (not talking about actually being able to use that module), or we go with groovy-all at the beginning.
But I do agree on the indy variant not having a different name... and actually it is not only the indy version of the groovy-all. There are indy versions of all the jars
bye Jochen
