Indy vs default build

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Indy vs default build

Russel Winder-3
In Groovy 3.0 there is still the default build and the indy artefacts
build – which I am guessing no-one uses because they are not the
default. Isn't 3.0 the time to get rid of this double build and just
have one build?

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:[hidden email]
41 Buckmaster Road    m: +44 7770 465 077   xmpp: [hidden email]
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Daniel Sun
+1 for setting indy by default.

Cheers,
Daniel.Sun
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Jennifer Strater
+1 

Regards,
Jenn

On Sun, May 28, 2017 at 2:22 PM, Daniel Sun <[hidden email]> wrote:
+1 for setting indy by default.

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Indy-vs-default-build-tp5741393p5741394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Mario Garcia
+1 Indy by default

Cheers
Mario

2017-05-28 14:43 GMT+02:00 Jennifer Strater <[hidden email]>:
+1 

Regards,
Jenn

On Sun, May 28, 2017 at 2:22 PM, Daniel Sun <[hidden email]> wrote:
+1 for setting indy by default.

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Indy-vs-default-build-tp5741393p5741394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Cédric Champeau
"Indy by default" doesn't mean anything. It's either "get rid of old call site caching/only keep indy" or, "keep as is".

Last time we tentatively started a discussion on what should be in Groovy 3 or not, we talked about upgrading to Java 8 minimally. If this happens, then we can use indy only and get rid of the "old" call site caching. But I also mentioned back then that we MUST perform benchmarks to make sure the performance of this version is as good as the previous one. Especially, I recall there were performance regressions in some areas (primitive handling, for example).

Also, bumping to Java 8 only may be an issue for some. At least, it would prevent Gradle from upgrading to Groovy 3. Which may, or may not be an issue.


2017-05-29 8:20 GMT+02:00 Mario Garcia <[hidden email]>:
+1 Indy by default

Cheers
Mario

2017-05-28 14:43 GMT+02:00 Jennifer Strater <[hidden email]>:
+1 

Regards,
Jenn

On Sun, May 28, 2017 at 2:22 PM, Daniel Sun <[hidden email]> wrote:
+1 for setting indy by default.

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Indy-vs-default-build-tp5741393p5741394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

paulk_asert
Master is already at Java 8 and will be the basis for Groovy 3 (or possibly 4 if we bump the 2_6 branch to be Groovy 3). So I think it's safe to target master for indy only. But agree we need to assess performance regressions.


On 29 May 2017 9:21 am, "Cédric Champeau" <[hidden email]> wrote:
"Indy by default" doesn't mean anything. It's either "get rid of old call site caching/only keep indy" or, "keep as is".

Last time we tentatively started a discussion on what should be in Groovy 3 or not, we talked about upgrading to Java 8 minimally. If this happens, then we can use indy only and get rid of the "old" call site caching. But I also mentioned back then that we MUST perform benchmarks to make sure the performance of this version is as good as the previous one. Especially, I recall there were performance regressions in some areas (primitive handling, for example).

Also, bumping to Java 8 only may be an issue for some. At least, it would prevent Gradle from upgrading to Groovy 3. Which may, or may not be an issue.


2017-05-29 8:20 GMT+02:00 Mario Garcia <[hidden email]>:
+1 Indy by default

Cheers
Mario

2017-05-28 14:43 GMT+02:00 Jennifer Strater <[hidden email]>:
+1 

Regards,
Jenn

On Sun, May 28, 2017 at 2:22 PM, Daniel Sun <[hidden email]> wrote:
+1 for setting indy by default.

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Indy-vs-default-build-tp5741393p5741394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Cédric Champeau
Right, I realize that it's not as easy as "remove" either, because otherwise you just break the ability to use libraries compiled with older versions of Groovy (which would be a pity). So if we go with indy "by default", we have to think what it means in terms of deliverables (a `-legacy` jar?) and what it means for consumers of those artifacts (imagine the number of projects which depend on `groovy-all` today).

2017-05-29 14:56 GMT+02:00 Paul King <[hidden email]>:
Master is already at Java 8 and will be the basis for Groovy 3 (or possibly 4 if we bump the 2_6 branch to be Groovy 3). So I think it's safe to target master for indy only. But agree we need to assess performance regressions.


On 29 May 2017 9:21 am, "Cédric Champeau" <[hidden email]> wrote:
"Indy by default" doesn't mean anything. It's either "get rid of old call site caching/only keep indy" or, "keep as is".

Last time we tentatively started a discussion on what should be in Groovy 3 or not, we talked about upgrading to Java 8 minimally. If this happens, then we can use indy only and get rid of the "old" call site caching. But I also mentioned back then that we MUST perform benchmarks to make sure the performance of this version is as good as the previous one. Especially, I recall there were performance regressions in some areas (primitive handling, for example).

Also, bumping to Java 8 only may be an issue for some. At least, it would prevent Gradle from upgrading to Groovy 3. Which may, or may not be an issue.


2017-05-29 8:20 GMT+02:00 Mario Garcia <[hidden email]>:
+1 Indy by default

Cheers
Mario

2017-05-28 14:43 GMT+02:00 Jennifer Strater <[hidden email]>:
+1 

Regards,
Jenn

On Sun, May 28, 2017 at 2:22 PM, Daniel Sun <[hidden email]> wrote:
+1 for setting indy by default.

Cheers,
Daniel.Sun



--
View this message in context: http://groovy.329449.n5.nabble.com/Indy-vs-default-build-tp5741393p5741394.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Jochen Theodorou
In reply to this post by Cédric Champeau


On 29.05.2017 09:21, Cédric Champeau wrote:
> "Indy by default" doesn't mean anything. It's either "get rid of old
> call site caching/only keep indy" or, "keep as is".

Completely ripping out the old callsite caching means old code will no
longer work. Having both, but using indy as default will not be a
breaking change for binary compatibility. And the old callsite caching
could be rewritten to use indy as well. We would still get rid of most
of the callsite caching code then. This means we can make this a two
step approach. First have both, but let the old code use indy. And then
get rid of the old part completely ind the big breaking change version

[...]
> Also, bumping to Java 8 only may be an issue for some. At least, it
> would prevent Gradle from upgrading to Groovy 3. Which may, or may not
> be an issue.

If it is a big binary breaking version this Gradle will not adapt that
Groovy version anytime anyway. Right?

bye Jochen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Cédric Champeau


If it is a big binary breaking version this Gradle will not adapt that Groovy version anytime anyway. Right?

It needs to be binary compatible (so that precompiled plugins still work) *and* compatible with JDK 7 (which is the minimal runtime for Gradle). When I say this may or may not be an issue, it's because by the time Groovy 3 is released, maybe Gradle would require Java 8, I really don't know. Or, if not, we could decide to stay on Groovy 2.x, since Gradle Script Kotlin is supposed to be the default in the future.
 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Indy vs default build

Jochen Theodorou


On 29.05.2017 18:50, Cédric Champeau wrote:
> [...]  Or, if not, we could decide to stay on Groovy 2.x, since
> Gradle Script Kotlin is supposed to be the default in the future.

I don't think it would be good if gradle stayed on Groovy 2.x. That
would counter the acceptance of Groovy 3

bye Jochen
12
Loading...