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:53:31 GMT
I like groovy-standalone.jar as a name (clearer than "all").
Alas changing names breaks all internet guides/posts/etc preceeding the 
name change, so one has to be careful with things like this...

On 22.11.2017 23:33, Leonard Brünings wrote:
>
> If you are doing that then most likely you won't be using the module 
> path either, so we could have groovy-standalone.jar,
> with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to 
> make it really obvious on what the proper usage is.
>
>
> Am 22.11.2017 um 21:58 schrieb Paul King:
>> The advantage with the fat jar is the convenience of being able to 
>> run Groovy without a dependency management system (Gradle/Maven). 
>> Java -jar with just the groovy-all jar is going to get you a long 
>> way. Then again, I bet most people who aren't using Gradle/Maven 
>> probably just download the distribution. So I see the groovy-all jar 
>> as a nice to have but not necessarily essential.
>>
>> Cheers, Paul.
>>
>> On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings 
>> <groovy-dev@bruenings-it.net <mailto:groovy-dev@bruenings-it.net>> 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>
>>             <mailto: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>
>>                 <mailto: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