groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: Building Groovy
Date Wed, 22 Nov 2017 18:41:10 GMT
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 <cedric.champeau@gmail.com 
> <mailto: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
>     <mailto: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