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.
2017-11-21 4:01 GMT+01:00 Leonard Brünings <groovy-...@bruenings-it.net>: > IMHO it is incorrect to have two different modules for normal and indy, > otherwise they are not interchangeable. You can't have both on the > classpath/modulepath anyway, since split packages are forbidden. > > Fatjars are not really compatible with Automatic-Module-Names, > since they can't export multiple modules. > > groovy-all-<version>.jar would need to export all individual modules, > which is not possible without module-info.java files. > > What would be possible is to have an aggregator jar that simply depends > on all other individual groovy jars to simulate this behavior. > > -Leo > > > > Am 21.11.2017 um 02:27 schrieb Daniel Sun: > >> How about the following proposal? >> >> `Automatic-Module-Name: org.apache.groovy.all` is for >> groovy-all-<version>.jar >> `Automatic-Module-Name: org.apache.groovy.all.indy` is for >> groovy-all-<version>-indy.jar >> `Automatic-Module-Name: org.apache.groovy` is for groovy-<version>.jar >> `Automatic-Module-Name: org.apache.groovy.xxx` is for >> groovy-xxx-<version>.jar (e.g. groovy-sql-3.0.0-SNAPSHOT.jar) >> >> Cheers, >> Daniel.Sun >> >> >> >> -- >> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> > >
