groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Wagenleitner <>
Subject Re: Indy vs default build
Date Wed, 31 May 2017 00:24:23 GMT
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)


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


On Tue, May 30, 2017 at 4:29 PM, Jochen Theodorou <> 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 <
>> <>>:
>>     > 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:
>> tp5741393p5741420.html
>>     <
>> tp5741393p5741420.html>
>>     Sent from the Groovy Dev mailing list archive at

View raw message