groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonard Brünings <>
Subject Re: Building Groovy
Date Wed, 22 Nov 2017 19:22:07 GMT
I agree with Cédric, that is also what I suggested before.

With maven/gradle the usage of groovy-all is currently done out of 

I think most projects would work just as well, if groovy-all would be 
turned into an
empty jar that just depends on the other jars.

Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
> Of course you arr right, I am more worried about the migration path in 
> combination with the final result.
> On 22.11.2017 14:30, Cédric Champeau wrote:
>> Said differently, if you depend on `groovy-all`, it will 
>> _effectively_ bring groovy, groovy-json, groovy-xml, groovy-...
>> All of those can be proper modules (as long as we fix the split 
>> packages). Then if someone else only brings in `groovy` + 
>> `groovy-json`, there's no conflict.
>> 2017-11-22 14:29 GMT+01:00 Cédric Champeau < 
>> <>>:
>>     That's precisely what I'm saying: we don't need a fat jar. We need a
>>     _module_ (Maven/Gradle sense of a module), which brings in the jars
>>     of the individual modules (JPMS sense). So there's no such think as
>>     a fat jar anymore, we don't need it.
>>     2017-11-22 14:26 GMT+01:00 Jochen Theodorou <
>>     <>>:
>>         Am 22.11.2017 um 11:47 schrieb Cédric Champeau:
>>             What is the advantage of providing a fat jar, if you can
>>             have a "virtual" dependency, groovy-all, which brings all
>>             the others in? There used to be a difference, but now it's
>>             not that clear.
>>         How are you going to express dependencies with automatic
>>         modules? They are automatic, because they lack the information a
>>         proper module provides and part of that information is the
>>         dependencies afaik. JPMS != maven.
>>         If you want groovy-all to bring in all the dependencies, then
>>         basically it is an almost empty jar with dependencies and the
>>         dependencies are the real modules. the fat-jar itself cannot
>>         provide any packages those dependencies to provide, otherwise
>>         you have conflicts. The empty groovy-all-approach is something
>>         we could go for in maven too of course. But its is not a fatjar
>>         then ;)
>>         bye Jochen

View raw message