groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: Building Groovy
Date Thu, 23 Nov 2017 11:14:03 GMT
-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>:

> 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>
> Datum: 23.11.17 02:43 (GMT+01:00)
> An: 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> 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> 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