Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
MIME-Version: 1.0
In-Reply-To: <c719af06-8ed2-a88f-1fac-3c607bf15185@gmx.org>
References: <1511232200.5526.6.camel@winder.org.uk> <CAMbkE7SsMqo5gB0r+vRUj6_gAVkLwcUT+uZmCaJHk=rxenzQRw@mail.gmail.com>
 <e8e7abe1-0785-4df2-ace3-fb9e22a81add@gmx.org> <1511341608.23523.0.camel@winder.org.uk>
 <CADQzvmn_5Q3ZAq6Fb1YTg=TsEZ=8x-TFAs+APMtQYdQS0gnaoA@mail.gmail.com> <c719af06-8ed2-a88f-1fac-3c607bf15185@gmx.org>
From: =?UTF-8?Q?C=C3=A9dric_Champeau?= <cedric.champeau@gmail.com>
Date: Wed, 22 Nov 2017 11:47:26 +0100
Message-ID: <CADQzvmmLb+p6Dd1pVK5nfDrUYXiK8Zma7ff05D7FmKFN3x2wzw@mail.gmail.com>
Subject: Re: Building Groovy
To: dev@groovy.apache.org
Content-Type: multipart/alternative; boundary="94eb2c004534a59c79055e900b27"
archived-at: Wed, 22 Nov 2017 10:47:39 -0000

--94eb2c004534a59c79055e900b27
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

2017-11-22 11:45 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org>:

>
>
> Am 22.11.2017 um 10:09 schrieb C=C3=A9dric Champeau:
>
>> To me it's very clear that Groovy.next is indy only, so all the
>> discussions we have about module names or call site caching are solved.
>>
>
> for the transition time from Groovy not as module and Groovy as module we
> require a discussion. Not about the indy versions, but about the fatjar.
> Unless my arguments before are good enough and we use different names for
> the fatjar and the proper module jars.
>
> Btw, In my eyes there is zero advantage for Groovy as module. The step is
> only required to not be at disadvantage, or even being ruled out as
> possibility. Of course the bigger required breaking changes may have the
> same effect
>
> bye Jochen
>

--94eb2c004534a59c79055e900b27
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What is the advantage of providing a fat jar, if you can h=
ave a &quot;virtual&quot; dependency, groovy-all, which brings all the othe=
rs in? There used to be a difference, but now it&#39;s not that clear.</div=
><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-11-22 11:45=
 GMT+01:00 Jochen Theodorou <span dir=3D"ltr">&lt;<a href=3D"mailto:blackdr=
ag@gmx.org" target=3D"_blank">blackdrag@gmx.org</a>&gt;</span>:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D""><br>
<br>
Am 22.11.2017 um 10:09 schrieb C=C3=A9dric Champeau:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
To me it&#39;s very clear that Groovy.next is indy only, so all the discuss=
ions we have about module names or call site caching are solved.<br>
</blockquote>
<br></span>
for the transition time from Groovy not as module and Groovy as module we r=
equire a discussion. Not about the indy versions, but about the fatjar. Unl=
ess my arguments before are good enough and we use different names for the =
fatjar and the proper module jars.<br>
<br>
Btw, In my eyes there is zero advantage for Groovy as module. The step is o=
nly required to not be at disadvantage, or even being ruled out as possibil=
ity. Of course the bigger required breaking changes may have the same effec=
t<br>
<br>
bye Jochen<br>
</blockquote></div><br></div>

--94eb2c004534a59c79055e900b27--