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: <75ce295e-6b6a-c6d8-a50a-39b1c7880d38@gmx.org>
References: <1495957581.5732.2.camel@winder.org.uk> <1495974130703-5741394.post@n5.nabble.com>
 <CALH4Ct8GEUaQt15moKf8HL6dKxhpgZXzUNPNSUoj32cbpc50vA@mail.gmail.com>
 <CAJp1MBOuHP61SjxwBDp4yv1LLiwCsW8OBx3W0AUwPrKQpOpwMg@mail.gmail.com>
 <CADQzvm=M32thDwSqMbvzR7ZPAh5=kz-=B9r43v7dgPuA3iRhZw@mail.gmail.com>
 <be53e835-c32a-d3c6-9189-9d544766b5d7@gmx.org> <CADQzvmnbzjf_zQbVC=XOa9H-PPd6h1E3mHb7pzQT7Ad_-Y83fw@mail.gmail.com>
 <31c6fc75-8aa4-0fa7-bb6f-f47a81d814ee@gmx.org> <1496157883523-5741420.post@n5.nabble.com>
 <CAJp1MBNr_ZPnDkSHFnyxx2e5DZTawLEmXfyerbZOyqo59MhdvA@mail.gmail.com> <75ce295e-6b6a-c6d8-a50a-39b1c7880d38@gmx.org>
From: John Wagenleitner <john.wagenleitner@gmail.com>
Date: Tue, 30 May 2017 17:24:23 -0700
Message-ID: <CAHPL-J=AjABBYrp1B4bUD6TFxR7cLLVN0Y1TqBVLSEwB9nFXrQ@mail.gmail.com>
Subject: Re: Indy vs default build
To: dev@groovy.apache.org
Content-Type: multipart/alternative; boundary="089e082069843d09710550c6f14b"
archived-at: Wed, 31 May 2017 00:24:29 -0000

--089e082069843d09710550c6f14b
Content-Type: text/plain; charset="UTF-8"

Does indy by default mean

1.  only generate one set of groovy-* artifacts where any .groovy source
files in the Groovy source itself are compiled using indy (no more separate
indy jars)

or

2.  continue to have two sets of artifacts where the indy set would go in
lib/ by default and -noindy jars would exist that could replace them if old
callsite code is desired

I took Russel's original suggestion to mean #1 and I would be in favor of
that for 3.0. I think any performance concern would largely be confined to
some of the sub-projects in the Groovy codebase since most of core is
written in Java.

The other consideration in making indy default is whether indy will be
enabled by default for compiling user supplied source and this is what I
think most are referring to in the replies.  This is where I agree that
there is no rush to remove the callsite code and it would be good to have a
--no-indy option for the next several major versions after that change is
made.

John


On Tue, May 30, 2017 at 4:29 PM, Jochen Theodorou <blackdrag@gmx.org> wrote:

> in my opinion if JDK8 is the minimum requirement we can switch to indy as
> default, while keeping the old call site caching as is.
>
> It is more that in the long term we want to get rid of code that has no
> future and all that. But I see no hard requirement to do those things just
> because of indy beig the default
>
> bye Jochen
>
> On 30.05.2017 23:48, Mario Garcia wrote:
>
>> If I didn't get it wrong, there is a possibility to have indy as a
>> default only if:
>>
>>  1. Callsite caching is rewritten to work with indy/no indy
>>  2. We keep binary compatibility Groovy 3 / JDK7 until Gradle moves to
>>     Groovy 3
>>  3. Then we will be able to move to Groovy with JDK8 and set Indy by
>> default
>>
>> Is that correct ?
>> Mario
>>
>> 2017-05-30 17:24 GMT+02:00 Daniel Sun <realbluesun@hotmail.com
>> <mailto:realbluesun@hotmail.com>>:
>>
>>     > I don't think it would be good if gradle stayed on Groovy 2.x. That
>> would
>>     counter the acceptance of Groovy 3
>>
>>     Agreed.
>>
>>     Cheers,
>>     Daniel.Sun
>>
>>
>>
>>
>>     --
>>     View this message in context:
>>     http://groovy.329449.n5.nabble.com/Indy-vs-default-build-
>> tp5741393p5741420.html
>>     <http://groovy.329449.n5.nabble.com/Indy-vs-default-build-
>> tp5741393p5741420.html>
>>     Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>>

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

<div dir=3D"ltr">Does indy by default mean<div><br></div><div>1. =C2=A0only=
 generate one set of groovy-* artifacts where any .groovy source files in t=
he Groovy source itself are compiled using indy (no more separate indy jars=
)</div><div><br></div><div>or=C2=A0</div><div><br></div><div>2. =C2=A0conti=
nue to have two sets of artifacts where the indy set would go in lib/ by de=
fault and -noindy jars would exist that could replace them if old callsite =
code is desired</div><div><br></div><div>I took Russel&#39;s original sugge=
stion to mean #1 and I would be in favor of that for 3.0. I think any perfo=
rmance concern would largely be confined to some of the sub-projects in the=
 Groovy codebase since most of core is written in Java.</div><div><br></div=
><div>The other consideration in making indy default is whether indy will b=
e enabled by default for compiling user supplied source and this is what I =
think most are referring to in the replies.=C2=A0 This is where I agree tha=
t there is no rush to remove the callsite code and it would be good to have=
 a --no-indy option for the next several major versions after that change i=
s made.</div><div><br></div><div>John<br></div><div><br></div></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, May 30, 2017 at =
4:29 PM, Jochen Theodorou <span dir=3D"ltr">&lt;<a href=3D"mailto:blackdrag=
@gmx.org" target=3D"_blank">blackdrag@gmx.org</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">in my opinion if JDK8 is the minimum requirement=
 we can switch to indy as default, while keeping the old call site caching =
as is.<br>
<br>
It is more that in the long term we want to get rid of code that has no fut=
ure and all that. But I see no hard requirement to do those things just bec=
ause of indy beig the default<br>
<br>
bye Jochen<span class=3D""><br>
<br>
On 30.05.2017 23:48, Mario Garcia wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
If I didn&#39;t get it wrong, there is a possibility to have indy as a<br>
default only if:<br>
<br></span>
=C2=A01. Callsite caching is rewritten to work with indy/no indy<br>
=C2=A02. We keep binary compatibility Groovy 3 / JDK7 until Gradle moves to=
<br>
=C2=A0 =C2=A0 Groovy 3<br>
=C2=A03. Then we will be able to move to Groovy with JDK8 and set Indy by d=
efault<span class=3D""><br>
<br>
Is that correct ?<br>
Mario<br>
<br>
2017-05-30 17:24 GMT+02:00 Daniel Sun &lt;<a href=3D"mailto:realbluesun@hot=
mail.com" target=3D"_blank">realbluesun@hotmail.com</a><br></span>
&lt;mailto:<a href=3D"mailto:realbluesun@hotmail.com" target=3D"_blank">rea=
lbluesun@hotmail.co<wbr>m</a>&gt;&gt;:<span class=3D""><br>
<br>
=C2=A0 =C2=A0 &gt; I don&#39;t think it would be good if gradle stayed on G=
roovy 2.x. That would<br>
=C2=A0 =C2=A0 counter the acceptance of Groovy 3<br>
<br>
=C2=A0 =C2=A0 Agreed.<br>
<br>
=C2=A0 =C2=A0 Cheers,<br>
=C2=A0 =C2=A0 Daniel.Sun<br>
<br>
<br>
<br>
<br>
=C2=A0 =C2=A0 --<br>
=C2=A0 =C2=A0 View this message in context:<br>
=C2=A0 =C2=A0 <a href=3D"http://groovy.329449.n5.nabble.com/Indy-vs-default=
-build-tp5741393p5741420.html" rel=3D"noreferrer" target=3D"_blank">http://=
groovy.329449.n5.nabble<wbr>.com/Indy-vs-default-build-<wbr>tp5741393p57414=
20.html</a><br>
=C2=A0 =C2=A0 &lt;<a href=3D"http://groovy.329449.n5.nabble.com/Indy-vs-def=
ault-build-tp5741393p5741420.html" rel=3D"noreferrer" target=3D"_blank">htt=
p://groovy.329449.n5.nabbl<wbr>e.com/Indy-vs-default-build-<wbr>tp5741393p5=
741420.html</a>&gt;<br>
=C2=A0 =C2=A0 Sent from the Groovy Dev mailing list archive at Nabble.com.<=
br>
<br>
<br>
</span></blockquote>
</blockquote></div><br></div>

--089e082069843d09710550c6f14b--