About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

["Daniel.Sun" <su...@apache.org>]

Hi all,

    As Leonard Brünings suggested[1], we should exclude the auto-generated
module-info.class file and set a stable module name with
`Automatic-Module-Name` entry in MANIFEST[2].

    How about setting `Automatic-Module-Name: org.apache.groovy` entry for
all versions(i.e. 2.4.x, 2.5.x, 2.6.x, 3.0.x)?

Cheers,
Daniel.Sun

[1]
http://groovy.329449.n5.nabble.com/Compiling-groovy-with-java9-using-maven-with-spring-boot-tp5744648p5744667.html
[2] https://github.com/mockito/mockito/issues/1189



--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Re: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[Jochen Theodorou <bl...@gmx.org>]

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

Re: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[Cédric Champeau <ce...@gmail.com>]

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 <gr...@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
>>
>
>

Re: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[Leonard Brünings <gr...@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

RE: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[Daniel Sun <re...@hotmail.com>]

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

RE: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[er...@thomsonreuters.com]

Shouldn't it be different for each groovy-xxx.jar?  What should it be for groovy-all.jar, which contains the stuff of many modules?  What about the indy jars?  Do they have a separate module name or a shared name with their non-indy counterparts?