groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonard Brünings <groovy-...@bruenings-it.net>
Subject Re: Building Groovy
Date Wed, 22 Nov 2017 22:33:21 GMT
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