groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: Building Groovy
Date Wed, 22 Nov 2017 13:30:27 GMT
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 <cedric.champeau@gmail.com>:

> 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 <blackdrag@gmx.org>:
>
>>
>>
>> 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
>>
>
>

Mime
View raw message