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 Thu, 23 Nov 2017 17:07:15 GMT
So what exactly do we disagree on here? Adding a fatjar? We have one 
right now, so adding is beyond the point. Making the fatjar provide a 
name for the automatic module naming in JPMS? Changing the fatjar to a 
lean jar, that just references all the other jars in a build system and 
that cannot do so as automatic module?

I lost the point of this thread

Am 23.11.2017 um 12:14 schrieb Cédric Champeau:
> -1 for adding a fat jar, whatever it is. I sincerely doubt a lot of 
> people use this directly with `java -jar ...`. Either you use the 
> distribution, and we would setup the classpath for you, or you use a 
> build tool, and it's also done for you. And I doubt large companies 
> without access to internet don't use build tools. We have quite evidence 
> of the contrary (they tend to use internal repositories).
> 
> 2017-11-23 12:08 GMT+01:00 mg <mgbiz@arscreat.com 
> <mailto:mgbiz@arscreat.com>>:
> 
>     I was thinking the same. Without being all for changing the name, maybe:
>     groovy-single.jar
>     groovy-fat.jar
>     groovy-the-one.jar
>     (or more fluent: the-one-groovy.jar ;-) )
>     ?
> 
>     -------- Ursprüngliche Nachricht --------
>     Von: Paul King <paulk@asert.com.au <mailto:paulk@asert.com.au>>
>     Datum: 23.11.17 02:43 (GMT+01:00)
>     An: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
>     Betreff: Re: Building Groovy
> 
>     The issue we sometimes get with names like "standalone" (and even
>     "all") is that sometimes folks assume that means with all optional
>     dependencies embedded like ivy, commons-cli, junit etc. I am not
>     saying that "standalone" is any worse than "all", just a point to
>     keep in mind when picking names ...
> 
>     Cheers, Paul.
> 
> 
>     On Thu, Nov 23, 2017 at 8:53 AM, MG <mgbiz@arscreat.com
>     <mailto:mgbiz@arscreat.com>> wrote:
> 
>         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