Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
From: Jochen Theodorou <blackdrag@gmx.org>
Subject: Re: Building Groovy
To: Paul King <paulk@asert.com.au>, dev@groovy.apache.org
References: <1511232200.5526.6.camel@winder.org.uk>
 <CAMbkE7SsMqo5gB0r+vRUj6_gAVkLwcUT+uZmCaJHk=rxenzQRw@mail.gmail.com>
Message-ID: <e8e7abe1-0785-4df2-ace3-fb9e22a81add@gmx.org>
Date: Tue, 21 Nov 2017 17:38:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <CAMbkE7SsMqo5gB0r+vRUj6_gAVkLwcUT+uZmCaJHk=rxenzQRw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
archived-at: Tue, 21 Nov 2017 16:38:16 -0000


Am 21.11.2017 um 08:28 schrieb Paul King:
> The "double" build is because of indy vs non-indy (one wipes out the 
> other) because of some assumptions that keep other parts of the build 
> simple. Could no doubt be streamlined given some TLC.
> 
> Last I checked there were different performance characteristics between 
> indy/non-indy. We haven't gotten around to working out the best path 
> forward yet that will give us one set of jars without losing performance 
> in some scenarios. Again, just needs some time dedicated to it.

I don't see the old callsite caching still working properly in a Java9 
world, so it is time to cut loose

bye Jochen