groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Building Groovy
Date Wed, 22 Nov 2017 22:44:45 GMT
I also agree.
The one argument I see for a fat groovy-all, is that it lowers the 
hurdle of trying Groovy in your project, if you are in a (e.g. secure) 
environment where you cannot use Maven/Gradle to pull in all 
dependencies from the internet.

On 22.11.2017 20:22, Leonard Brünings wrote:
> 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 
> convenience.
>
> 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 
>>> <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