Trouble building Groovy 3 jars

I'm attempting to backport the changes required to fix GROOVY-10201 from the main branch to the GROOVY_3_0_X branch, but I'm hitting a weird problem. I'd like to first test that the changes work and hopefully submit a pull request to get them into 3.0.10. I've cherry-picked the changes and

Re: Building Groovy

But the fact that it is an internal implementation detail does not prohibit technical minded people to be interested in them. Most developers I have met were interested in such things. Most men have e.g. at least some knowledge about the inner workings of their car, even if that are internal

Re: Building Groovy

> > > I disagree. 99% of our users don't even know what call site caching is. > They don't know what invokedynamic means, > > > You think that 99% of Java professionals do not know what a feature that > has been around since Java 7 is ? > And even if that was the case: Google "java invoke dynamic"

Re: Building Groovy

I have another thread dedicated to the discussion of the forum. Ironically, my post is marked as "not being accepted by the mailing list" despite there being replies, but now my follow up posts aren't showing up, so I don't know if the discussion can continue there. Here is the thread:

Re: Building Groovy

On 21.12.2017 01:48, Nathan Harvey wrote: Although I think this discussion is getting off topic, I'll go ahead and chime in myself. I would once again remind people that a strong open source community is built on public communications. Mailing lists are old, they are fickle, they are annoying,

Re: Building Groovy

Although I think this discussion is getting off topic, I'll go ahead and chime in myself. I would once again remind people that a strong open source community is built on public communications. Mailing lists are old, they are fickle, they are annoying, and the list goes on. If Groovy wants to

Re: Building Groovy

On 19.12.2017 18:23, Paul King wrote: I agree with earlier comments in particular from Jochen and Cédric. I also suspect that JDK 9 issues may force us down the indy only path at some point not too far away and I think we just have to keep optimising the common cases in the meantime using some

Re: Building Groovy

On 19.12.2017 09:37, Cédric Champeau wrote: 2017-12-19 2:21 GMT+01:00 MG >: Hmmm, I don't know if Paul has some comeback, but to me you make a very convincing point... In that case the best way forward to me seems to be to 1) Ask

Re: Building Groovy

On Tue, Dec 19, 2017 at 11:21 AM, MG wrote: > Hmmm, I don't know if Paul has some comeback, but to me you make a very > convincing point... > I agree with earlier comments in particular from Jochen and Cédric. I also suspect that JDK 9 issues may force us down the indy only

Re: Building Groovy

2017-12-19 2:21 GMT+01:00 MG : > Hmmm, I don't know if Paul has some comeback, but to me you make a very > convincing point... > In that case the best way forward to me seems to be to > 1) Ask non-@CompileStatic Groovy users who can afford the time to switch > to the invoke

Re: Building Groovy

Hmmm, I don't know if Paul has some comeback, but to me you make a very convincing point... In that case the best way forward to me seems to be to 1) Ask non-@CompileStatic Groovy users who can afford the time to switch to the invoke dynamic variety of the Groovy jars and report back on

Re: Building Groovy

On 18.12.2017 01:01, MG wrote: Just came across this as an example where using Groovy 2.4.6 invokedynamic seems to have been much slower than the older callsite caching mechanism: https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones

Re: Building Groovy

Just came across this as an example where using Groovy 2.4.6 invokedynamic seems to have been much slower than the older callsite caching mechanism: https://www.linkedin.com/pulse/how-make-groovy-fast-java-david-e-jones (https://dzone.com/articles/how-to-make-groovy-as-fast-as-java) Quote:

Re: Building Groovy

com.au>>     Datum: 23.11.17 02:43 (GMT+01:00)     An: dev@groovy.apache.org <mailto:dev@groovy.apache.org>     Betreff: Re: Building Groovy     The issue we sometimes get with names like "standalone" (and even     "all") is that sometimes folks assume that means with

Re: Building Groovy

m.au <mailto:pa...@asert.com.au>> Datum: 23.11.17 02:43 (GMT+01:00) An: dev@groovy.apache.org <mailto:dev@groovy.apache.org> Betreff: Re: Building Groovy The issue we sometimes get with names like "standalone" (and even "all") is that sometimes folks as

Re: Building Groovy

+01:00) An: dev@groovy.apache.org Betreff: Re: Building Groovy -1 for adding a fat jar, whatever it is. I sincerely doubt a lot of people use this directly with `java -jar ...`. Either you use the distribution, and we would setup the classpath for you, or you use a build tool, and it's also done f

Re: Building Groovy

groovy-the-one.jar > (or more fluent: the-one-groovy.jar ;-) ) > ? > > Ursprüngliche Nachricht > Von: Paul King <pa...@asert.com.au> > Datum: 23.11.17 02:43 (GMT+01:00) > An: dev@groovy.apache.org > Betreff: Re: Building Groovy > > The issue we som

Re: Building Groovy

n: dev@groovy.apache.org Betreff: Re: Building Groovy The issue we sometimes get with names like "standalone" (and even "all") is that sometimes folks assume that means with all optional dependencies embedded like ivy, commons-cli, junit etc. I am not saying that "standalone&

Re: Building Groovy

The issue we sometimes get with names like "standalone" (and even "all") is that sometimes folks assume that means with all optional dependencies embedded like ivy, commons-cli, junit etc. I am not saying that "standalone" is any worse than "all", just a point to keep in mind when picking names

Re: Building Groovy

I did download the distribution a few years back, but still added groovy-all to my project, since it is simply more convenient and groovy-all sounds like it is the thing you want. If Groovy is just something you are giving a shot, and you have a lot of things to evaluate, you naturally  want to

Re: Building Groovy

I like groovy-standalone.jar as a name (clearer than "all"). Alas changing names breaks all internet guides/posts/etc preceeding the name change, so one has to be careful with things like this... On 22.11.2017 23:33, Leonard Brünings wrote: If you are doing that then most likely you won't be

Re: Building Groovy

I also agree. The one argument I see for a fat groovy-all, is that it lowers the hurdle of trying Groovy in your project, if you are in a (e.g. secure) environment where you cannot use Maven/Gradle to pull in all dependencies from the internet. On 22.11.2017 20:22, Leonard Brünings wrote: I

Re: Building Groovy

If you are doing that then most likely you won't be using the module path either, so we could have groovy-standalone.jar, with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to make it really obvious on what the proper usage is. Am 22.11.2017 um 21:58 schrieb Paul King: The

Re: Building Groovy

The advantage with the fat jar is the convenience of being able to run Groovy without a dependency management system (Gradle/Maven). Java -jar with just the groovy-all jar is going to get you a long way. Then again, I bet most people who aren't using Gradle/Maven probably just download the

Re: Building Groovy

I agree with Cédric, that is also what I suggested before. With maven/gradle the usage of groovy-all is currently done out of convenience. I think most projects would work just as well, if groovy-all would be turned into an empty jar that just depends on the other jars. Am 22.11.2017 um

Re: Building Groovy

Of course you arr right, I am more worried about the migration path in combination with the final result. On 22.11.2017 14:30, Cédric Champeau wrote: Said differently, if you depend on `groovy-all`, it will _effectively_ bring groovy, groovy-json, groovy-xml, groovy-... All of those can be

Re: Building Groovy

Said differently, if you depend on `groovy-all`, it will _effectively_ bring groovy, groovy-json, groovy-xml, groovy-... All of those can be proper modules (as long as we fix the split packages). Then if someone else only brings in `groovy` + `groovy-json`, there's no conflict. 2017-11-22 14:29

Re: Building Groovy

That's precisely what I'm saying: we don't need a fat jar. We need a _module_ (Maven/Gradle sense of a module), which brings in the jars of the individual modules (JPMS sense). So there's no such think as a fat jar anymore, we don't need it. 2017-11-22 14:26 GMT+01:00 Jochen Theodorou

Re: Building Groovy

Am 22.11.2017 um 11:47 schrieb Cédric Champeau: 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. How are you going to express dependencies with

Re: Building Groovy

On Wed, 2017-11-22 at 09:53 +, Remi Forax wrote: > Do you have a problem with those people ? :) Not at all, but I am unlikely to be one of them as I am doing native code stuff now. If I was still using JVM, it would be OpenJDK10, OpenJDK9 is so passè, and OpenJDK8 must be close to retirement

Re: Building Groovy

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 : > > > Am 22.11.2017 um 10:09 schrieb

Re: Building Groovy

Am 22.11.2017 um 10:09 schrieb Cédric 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

Re: Building Groovy

Do you have a problem with those people ? :) Rémi On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder wrote: >On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote: >> >[…] >> I don't see the old callsite caching still working properly in a >> Java9 >> world,

Re: Building Groovy

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. 2017-11-22 10:06 GMT+01:00 Russel Winder : > On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote: > > > […] > > I don't see the old

Re: Building Groovy

On Tue, 2017-11-21 at 17:38 +0100, Jochen Theodorou wrote: > […] > I don't see the old callsite caching still working properly in a > Java9 > world, so it is time to cut loose > And now of course people will be using OpendJDK10 ;-) -- Russel. === Dr

Re: Building Groovy

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

Building Groovy

Hi, It seems that building Groovy immediately after building Groovy means everything is compiled again. Surely what should be a null build should take 0 seconds rather than 5 minutes? (A null build taking 5 minutes rather than 0 seconds would, in the native code world, indicate a failed build