Re: [Fwd: Processed: tagging 927056]
On Mon, 2019-04-15 at 15:55 +1000, Paul King wrote: > We should have that gone in 3.0 beta 1 soonish. What version do they > normally bundle? Debian is currently packaging 2.4.16, which is clearly not the version they should be packaging. Linuxbrew packages 2.5.6. > > On Mon, Apr 15, 2019 at 3:40 PM Russel Winder > wrote: > > > I get the feeling that the "illegal reflective access" message from > > Groovy, may very soon become a reason Groovy isn't in Debian. > > > > Forwarded Message > > From: Debian Bug Tracking System > > To: … > > Cc: pkg-java-maintain...@lists.alioth.debian.org > > Subject: Processed: tagging 927056 > > Date: Mon, 15 Apr 2019 02:57:04 + > > > > > Processing commands for cont...@bugs.debian.org: > > > > > > > tags 927056 + confirmed > > > Bug #927056 [groovy] groovy: Groovy gives warning with OpenJDK 11 > > > about illegal reflective access > > > Added tag(s) confirmed. > > > > thanks > > > Stopping processing here. > > > > > > Please contact me if you need assistance. > > > -- > > > 927056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927056 > > > Debian Bug Tracking System > > > Contact ow...@bugs.debian.org with problems > > > > > -- > > Russel. > > ======= > > Dr Russel Winder t: +44 20 7585 2200 > > 41 Buckmaster Roadm: +44 7770 465 077 > > London SW11 1EN, UK w: www.russel.org.uk > > > > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
[Fwd: Processed: tagging 927056]
I get the feeling that the "illegal reflective access" message from Groovy, may very soon become a reason Groovy isn't in Debian. Forwarded Message From: Debian Bug Tracking System To: … Cc: pkg-java-maintain...@lists.alioth.debian.org Subject: Processed: tagging 927056 Date: Mon, 15 Apr 2019 02:57:04 + > Processing commands for cont...@bugs.debian.org: > > > tags 927056 + confirmed > Bug #927056 [groovy] groovy: Groovy gives warning with OpenJDK 11 > about illegal reflective access > Added tag(s) confirmed. > > thanks > Stopping processing here. > > Please contact me if you need assistance. > -- > 927056: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927056 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gant is to be deleted, or will someone preserve it?
On Sat, 2019-02-02 at 09:50 +0100, Cédric Champeau wrote: > An alternative is to "archive" the project in GitHub. It's going to be > read-only (see the "settings" tab). > Gant organisation now with two owners not one, and the two repositories archived as proposed. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gant is to be deleted, or will someone preserve it?
On Tue, 2019-02-05 at 00:08 +1000, Paul King wrote: > +1 to archiving it. I am happy for you to add my name as a maintainer if > that helps. > I do feel I need to add another owner to the Gant Organisation before archiving, so if you are up for that, I think we have a way forward. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Status of GPars
Hi, I have come to the decision to stop working on GPars. I have done very little over the last year anyway, there has been no interest at all from the Groovy community, and I am not doing much with Groovy or even the JVM these days – except perhaps some Kotlin for writing the DLanguage CLion plugin. Clearly the GPars organisation is there on GitHub, with multiple owners, as is the source code. So there is no threat to the code, other than it is moribund and other solutions are overtaking it. In particular Quasar, Kotlin Coroutines, and Project Loom, are likely the future for much of the stuff in GPars. GPars still has features not available elsewhere on the JVM, but it has lost all momentum as a project. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gant is to be deleted, or will someone preserve it?
On Sat, 2019-02-02 at 09:18 +0100, Guillaume Laforge wrote: > Why deleting it? > Keep it for posterity! :-) Someone, or some people, then needs to step up and volunteer to be an owner of the Gant organisation on GitHub. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Cannot build Groovy "out of the box"
On Sun, 2018-08-19 at 10:44 +1000, Paul King wrote: > Yes, I fixed up compilation but didn't do doc yet. You are being a Groovy hero. :-) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Cannot build Groovy "out of the box"
On Sat, 2018-08-18 at 19:45 +0200, Remi Forax wrote: > yes, > JAXB has to be pulled from Maven Central now. > That is not the problem per se, the problem is that the Groovy javadoc process in master/HEAD assumes JAXB is in the classpath. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Cannot build Groovy "out of the box"
On Sat, 2018-08-18 at 15:42 +, Uwe Schindler wrote: > Hi, > > I assume you are building with Java 11! JAXB is unfortunately no > longer bundled/enabled in the JDK. > True, which shows that Groovy has a problem. Only 38 days till Java 11 is the current version of Java. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Cannot build Groovy "out of the box"
Since the JAXB thing, Groovy master/HEAD does not build out of the box: For example: > Task :javadocAll /home/users/russel/Repositories/Git/Forks/Groovy/subprojects/groovy-jaxb/src/main/java/org/apache/groovy/jaxb/extensions/JaxbExtensions.java:21: error: package javax.xml.bind does not exist import javax.xml.bind.JAXBContext; ^ /home/users/russel/Repositories/Git/Forks/Groovy/subprojects/groovy-jaxb/src/main/java/org/apache/groovy/jaxb/extensions/JaxbExtensions.java:22: error: package javax.xml.bind does not exist import javax.xml.bind.JAXBException; ^ Should there be a fix for this? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.2
+1 > > [ ] +1 Release Apache Groovy 2.5.2 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.2 because... > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [DRAFT] Proposed board report for August 2018
I appreciate the idea of big numbers is to impress, and clearly we want to be impressive, but do we know what is meant by download here? As I see it, we have: – Groovy installer downloads – Gradle/Maven/etc. direct downloads of a groovy artefact from: · Maven Central · JCenter – Gradle/Maven/etc. indirect (due to transitive dependency) downloads of a groovy artefact from: · Maven Central · JCenter This still ignores everyone using SDKMAN! to download the groovy system. Also Arch, Fedora, and Debian (and thus Ubuntu and Mint) package Groovy, and this defies any form of counting for impressiveness purposes. Of course there is also MacPorts, HomeBrew, and indeed Chocolatey. These statistics also don't recognise that there are Gradle and Maven caches that are being filled and copied, defying all statistics. I just get the feeling that the download statistics do not actually tell us anything useful. But if they keep people happy, they serve a purpose. On Wed, 2018-08-08 at 14:14 +0200, Guillaume Laforge wrote: > Looking great to me :-) > > Adding a few numbers: > > Apache Groovy was downloaded 27M+ times the past three months (May / June / > July), > across Maven Central and Bintray JCenter, for a total of 54M+ since the > beginning of the year. > Generally, 2/3 of the downloads are from Maven Central, vs 1/3 from Bintray > JCenter. > There is still a lot of users downloading the latest 2.4.x releases, almost > as much as the 2.5.x ones. > But it is nice to see that about 10% of the downloads are from users trying > our 3.0 alphas. > > Guillaume > > > > On Wed, Aug 8, 2018 at 12:04 PM Paul King wrote: > > > > > I haven't heard from Guillaume and our report is due today. > > I don't have the latest download numbers but here is all the rest of the > > info. > > > > Please let me know if you have anything to add. > > > > Cheers, Paul. > > P.S. Guillaume, please feel free to send or I while first thing my > > tomorrow. > > > > > > > > > > ## Description: > > > > Apache Groovy is a multi-faceted programming language for the Java > > platform. > > Groovy is a powerful, optionally typed and dynamic language, with static- > > typing and static compilation capabilities, aimed at multiplying > > developers’ > > productivity thanks to a concise, familiar and easy to learn syntax. It > > integrates smoothly with any Java program, and immediately delivers to > > your > > application powerful features, including scripting capabilities, Domain- > > Specific Language authoring, first class functional programming support > > and runtime and compile-time meta-programming. > > > > ## Issues: > > > > There are no new issues requiring board attention at this time. > > Outstanding issues: > > - The final steps to completing the website migration are still > > outstanding. > > > > ## Activity: > > > > - This quarter, 257 commits were contributed from 22 contributors > > including 12 non-committer contributors (12 new). > > > > ## Health report: > > > > - Committee Health score: 10.00 (Super Healthy) > > - Our release train velocity has been maintained, and there seems to be a > >healthy level of discussion about project direction on the mailing > > lists. > > > > ## PMC changes: > > > > - Currently 11 PMC members. > > - Andres Almiray was added to the PMC on Thu May 31 2018 > > > > ## Committer base changes: > > > > - Currently 19 committers. > > - Remko Popma was added as a committer on Sat Jul 07 2018 > > > > ## Releases: > > > > - 2.5.0 was released on Wed May 30 2018 > > - 2.5.0-rc-3 was released on Tue May 22 2018 > > - 2.5.1 was released on Fri Jul 13 2018 > > - 2.6.0-alpha-4 was released on Tue Jun 26 2018 > > - 3.0.0-alpha-3 was released on Tue Jun 26 2018 > > > > ## Mailing list activity: > > > > - Slight increase in subscribers over the period otherwise nothing to > > report > > > > ## JIRA activity: > > > > - 159 JIRA tickets created in the last 3 months > > - 133 JIRA tickets closed/resolved in the last 3 months > > > > > > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy JavadocAll task fails on JDK11
I just tried the Groovy build on Debian Sid OpenJDK11 and the javadocAll task fals with 12 errors mostly about JAXB-related stuff. Interestingly this fail didn't stop the installGroovy task from doing what it is supposed to do. Which is good. I notice that groovyConsole now obeys the GTK theme running on JDK11 with Gnome. This is good – except that with teh dark Gnome theme, the colour scheme for the syntax colouring of groovyConsole is still the light scheme so much of the text is totally invisible. groovyConsole needs a dark theme syntax colour scheme. Does anyone know how to do this? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Licence statements
On Wed, 2018-08-01 at 20:29 +1000, Paul King wrote: > Yes, Groovy 2.5.X has JDK7 as minimum and Groovy 3 has JDK8. From your > description, it seems like both don't need jsr116y. I'll refresh my memory > and run some tests and get rid of it assuming all goes to plan. That would be the right route I think. Try removing jsr166y.jar as a dependency run the tests, and I hope nothing breaks. > For GPars 2, it will be interesting to see whether we can have gpars-core, > gpars-asynch, gpars-dataflow, etc. modules or whether one fat module will > make sense. I am not sure about this, but that is because I haven't thought about it, not because I think it is necessarily a bad idea. In the post JDK8 world, the data parallel stuff in GPars is somewhat less important because of Stream. GPars actors, active objects, daflow, and CSP are the main features and I wonder if they should just be bundled together. Separating them means people have to do more configuration, is that a barrier too far for what, after all seems to be a not used library. The total lack of interest in the published GPars being so old, and progress on GPars 2 being so slow is a real turn off to putting in any effort on this. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Licence statements
On Wed, 2018-08-01 at 15:07 +1000, Paul King wrote: > Apologies for not answering earlier. I was travelling. No problem, travel has a higher priority. :-) > We bundle GPars and its transitive dependencies (including the jsr166y.jar) > in our install for Groovy. As per normal Apache guidelines we make the > licensing of anything we use/include crystal clear. OK, understood. The question is then whether jsr166y.jar should be distributed at all. As far as I remember jsr166y.jar is the bits of JDK 7 that are needed when running on JDK 6. If the minimum JDK version for Groovy is JDK7 then I believe jsr166y.jar is not needed. extra166y.jar is needed for GPars 1.X,but we had to make a few amendments and so took in internal fork into the GPars 1.X distribution. This means extra166y.jar is definitely not a dependency. > I guess in the JDK9+ world we should consider whether we want to still > include that dependency but perhaps we should put some further thinking > into GPars 2 and can then decide. I am assuming Groovy will treat JDK8 (despite it being a dead version of JDK :-) ) as it's base for now, or is there an intention to go to JDK9 (even though it is on it's last legs :-) )? In any event jsr166y.jar is an irrelevance and can be removed as a dependency. I guess if JDK9 is in play then GPars 2.0 ought to get packaged as a module. The extra166y fork is removed from GPars 2 because it is assumed things are running on at least JDK8. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Licence statements
I am wondering why there are all the licences for other products in the licenses directory of the Groovy Git repository. In particular as an example, why do we have jsr166y-BINZIP.txt and jsr166y-license.txt in this directory? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: bool
On Mon, 2018-07-23 at 16:35 +0200, mg wrote: > A quick search did not turn up anything on Kotlin using bool instead > of boolean. Do you have a link ? Maybe I just mis-remembered. If it is the case that Kotlin is using Boolean not Bool, then surely Java, Kotlin and Groovy all using Boolean is a consistency worth having? > To me brevity - as long as readability/code comprehension does not > suffer - is always a desirable feature.Otherwise Groovy's each would > be forEach or forEachElement or maybe even > applyClosureToEachElementInDefaultOrder.Other examples are println > which should be printLine or printInNewLine. Again println is println because Java has println. The core here is that Groovy does what Java does wherever possible. Resorting to stupid names such as applyClosureToEachElementInDefaultOrder is because Java in the 2000s got a very silly naming strategy for all the stupid types forced on people by various frameworks. each probably should be forEach. Many language introducing this higher order function went for that name. Groovy perhaps chose too early. But it is too late now, each it is. Similarly collect probably should have been map and inject probably should have been filter. However 2003 and Smalltalk. It is as it is. > "bool" in C++ at least seems to be from slightly before 2000, btw. It > seems the unwieldy "boolean" is actually the older term. And not a > well choosen one at that, since due to allowed values of [true, > false, null] in Java/Groovy the resulting algebra is actually not > Boolean (https://en.wikipedia.org/wiki/Boolean_algebra) :-) bool entered C++ in the ISO 98 standard, prior to that there was no boolean type, just an interpretation of integral values. For C it was C99 standard. Anything like boolean was a compiler-specific extension. The actual type prior to that was int. That C and C++ chose bool is as much to do with why they chose int as it is to do with readability or comprehensibility. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: bool
On Mon, 2018-07-23 at 12:40 +0200, mg wrote: > I wanted to keep my mail concise, but also aliasing Bool = Boolean > was more or less implied, for consistency & brevity reasons. > I would also think that Java would introduce Int = Integer, or use > int = Integer in that case... When it comes to these sorts of discussion excessive brevity can leave a lot of stuff missing! Clearly Kotlin is going these routes to make Java types more like C++ types, but I am not convinced this is a good idea. Shrinking type labels just to save a few keystrokes, or to conform to a 1970s view of type names, doesn't strike me as a good rationale. If however you could point to some psychology of programming experiments that proved code using bool rather than boolean and/or Bool rather than Boolean increased speed of code reading and comprehension, then you get my wholehearted backing for the change. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: bool
On Sun, 2018-07-22 at 23:39 +0200, MG wrote: > Hi, > > since things are going so well with my "fin" = "final" proposal, I > propose that Groovy support "bool" as a shortcut for "boolean". > > "boolean" is already seeing large scale use by Groovy developers, > "bool" > instead of "boolean" saves nearly half of the keyword's characters, > "bool" is used in C++, it fits better with the also widely used > "int", > and Groovy 3.0 is the ideal opportunity to introduce such language > extensions. > Isn't the long term intention to remove all primitive types from languages compiling to the JVM? Instead of int people are supposed to use Integer, instead of boolean people are supposed to use Boolean, and leave all the optimisation to the JVM. Is there any point in fiddling with Groovy primitive type names in this context? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: fin
On Sat, 2018-07-21 at 23:50 +0200, MG wrote:
> Hi guys,
>
> I have been wondering for a while whether Groovy developers use
> "def"
> even if a variable is actually is "final" not only because every
> Groovy
> example code uses "def", but also because "final" as a word is
> longer
> than "def".
> Therefore I propose to introduce the shortcut "fin" for "final" in
> Groovy.
Please don't.
final is just fine as it is.
> e.g. to support
>
> class Goo {
> fin String name
> fin Goo gooParent
> Goo(fin String name, fin Goo gooParent) { ... }
> String gooGoal(fin x) {
> fin y = 2*x
> fin int z = x + y
> }
> }
>
> Cheers,
> mg
1,$s/fin/final/g
>
>
--
Russel.
===
Dr Russel Winder t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK w: www.russel.org.uk
signature.asc
Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.1
+1 > [ ] +1 Release Apache Groovy 2.5.1 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.1 because... -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Building main/HEAD
On Mon, 2018-07-09 at 09:40 +1000, Paul King wrote: > Travis seems happy with openjdk10 on Ubuntu: > https://travis-ci.org/apache/groovy > And locally on Oracle JDK10.0.1 works for me too. > > Paul. OK, I think we can blame Gradle. I did a clean and then removed .gradle and buildSrc/.gradle and got a full build as required. > On Sun, Jul 8, 2018 at 11:22 PM Russel Winder > wrote: > > > Currently the generateGrammarSource is failing for me using JDK10 > > on Debian > > Sid. Is this to be expected? > > -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Building main/HEAD
On Mon, 2018-07-09 at 09:38 +1000, Paul King wrote: > Not expected. What is the error message? > Is there a way of trawling the Gradle build logs held by Gradle Inc? I have no way of accessing the URL as far as I can tell. :-( -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Building main/HEAD
Currently the generateGrammarSource is failing for me using JDK10 on Debian Sid. Is this to be expected? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 3.0.0-alpha-3
+1 -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Possible Problem
On Sat, 2018-06-16 at 11:35 -0700, John Wagenleitner wrote: > Looks like the problem is with the compound assignment using an attribute > and not related to synchronized. I created issue GROOVY-8648 [1] for this > problem. > > [1] https://issues.apache.org/jira/browse/GROOVY-8648 > John, Thanks for attacking this and discovering I had the wrong reason for the problem. Thanks also for creating the issue. I am now watching this and can try any experiments using master. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: 3.0.0-alpha-3
On Fri, 2018-06-15 at 14:15 -0700, Daniel.Sun wrote: > Hi Russel, > > There are some annoying bugs in 2.5.0, so it is better to release > 3.0.0-beta-3 after 2.5.1 is out. > OK. The 2.5 series is higher priority just now, so I'll wait. The workaround is to remove Groovy 3.0.0 from the Gant build, or just not fiddle with Gant till there is a 3.0.0-alpha-3 release. I, and the world, can cope with the latter. :-) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
3.0.0-alpha-3
3.0.0-alpha-2 doesn't have the commons/picocli stuff which is becoming a right PITA. Any chance of getting 3.0.0-alpha-3 out soon with this in place. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Possible Problem
I have been tinkering a bit with GPars,mostly as a reaction to JCP 1.1.0 being released (to replace my jcsp-1.1-rc-5 artefact). I amusing JDK11 and JDK10 with Groovy 2.5.0. In this example programme: https://github.com/GPars/GPars/blob/master/src/test/groovy/groovyx/gpars/samples/collections/DemoSynchronizedAccountTransfer.groovy It seems the synchronized keyword on the function credit line 29 is cause a problem during compilation: Error:Groovyc: ASM reporting processing error for groovyx.gpars.samples.collections.Account#credit with signature void credit(int) in DemoSynchronizedAccountTransfer.groovy:29 -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: New release of JCSP - (part of GPars) and groovyJCSP
Jon, On Thu, 2018-05-31 at 15:06 +, Kerridge, Jon wrote: > Russel > > I have yet to create a version of the library that is compiled for anything > other than groovy-2.4.12 and jdk8. > The former because in other work I am doing I cannot use any version above > groovy2.4.12 due to a bug I found. JDK 8 because I am lazy and waiting for > JDK 11 before doing any further recompilations in preparation for teaching!! I made the org.jcsp → jcsp change in the imports and all the code seems to compile with JDK10. There are some non-CSP problems to fix before I can run the tests, but it is looking good. Is the CSP stuff in GPars ancient compared to what you have now? If it is, should we contemplate a merge to update everything in GPars? […] -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build logs
On Thu, 2018-06-07 at 13:20 +0200, Cédric Champeau wrote: > I have added an explicit opt-in :) > I believe this is a good choice. Will it be persistent for the user on a given machine or will the question be asked every time there is a build? I am guessing CI is exempt from this. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build logs
On Thu, 2018-06-07 at 12:12 +0200, Cédric Champeau wrote: > I think you're right: currently the build uses `publishAlways()` and has > license accept enabled, but it should be per person. Cédric, Thanks for picking up I was being serious but trying to avoid seeming like "gammon". I suggest the road to de-personalisation would be not to collect user name, machine names, and machine IP addresses. In terms of logs, I can't see that they add anything. Clearly the rest of the data could be useful, and so is worth collecting. It is also nothing personal just data about a Groovy build on a particular machine, with machine details actually being important. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Gradle build logs
Cédric, I wonder if the Infrastructure section of the Gradle build log every Groovy build submits to Gradle constitutes personal information under the GDPR? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy build with Gradle 4.8
I think I lost an email, but I recollect Daniel asked me to build of Groovy master/HEAD with the new 4.8 Gradle. Tried it, seems to work fine. But it is now a matter of official record: https://gradle.com/s/eqtdqjr3nlagi -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Help needed for short presentation
Hi, I think I just volunteered to do a 35min presentation on Groovy In London sometime late summer. Given I haven't really used Groovy in about 4 or 5 years, I think it would be wise to take advice from the team on what to highlight to what will be fundamentally a Java audience for Groovy 2.5.0 and Groovy 3.0.0. I believe we can assume Java 8. Feel free to send emails privately and I will summarise. Thanks. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: New release of JCSP - (part of GPars) and groovyJCSP
On Thu, 2018-05-31 at 10:44 +, Kerridge, Jon wrote: > The JCSP library (Communicating Sequential Processes for Java) is now > available from the jcentre repository as follows: > > compile 'cspforjava:jcsp:1.1.0' > > The associated Github location is https://github.com/CSPforJAVA/jcsp > . Jon, This is great news, my hacked org.codehaus.jcsp:jcsp:1.1-rc-5 from 2010-08-07 can now be properly forgotten. I'll test out using cspforjava:jcsp:1.1.0 on a build of GPars 2.0 with Groovy 3 and JDK 10. I wonder if the JCenter artefact should be copied over to Maven Central? […] -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Groovy 2.5.0 release
On Thu, 2018-05-31 at 02:17 +1000, Paul King wrote: > Hi Russel, > > Yes it would have been nicer if we could have fitted an extra RC-4 > into the > schedule. In this instance, because Gant is totally irrelevant to the progress of the universe, unlike Groovy, I don't have an actual problem. > Anyway, to cut a long story short, I imagine you need the > groovy-cli-commons dependency added. I presume groovy-all isn't > bringing > that in which is an oversite on my part when I fixed up pointing the > deprecated groovy.util.CliBuilder to the > groovy.cli.commons.CliBuilder > rather than the newer but slightly different > groovy.cli.picocli.CliBuilder > which probably is in your path. If picocli is the future for Groovy CLI I may just drop Groovy 2.4 support from Gant (after all there are no Gant users, at least none prepared to say they are) and set up to go with picocli. > I'll add that to known issues on the release notes. Works for me. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy 2.5.0 release
Paul, There seems to be a difference between 2.5.0-rc-3 and 2.5.0, Gant compiled and ran all tests under the former, but fails to compile under the latter. This would seem to indicate a fail of release process since there was no 2.5.0-rc-4. 2.5.0-rc-3 had a class CliBuilder, 2.5.0 does not. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.0
+1 -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy 3 release
Hi, How much of: http://www.javamagazine.mozaicreader.com/MarApr2018/Twitter#=61=0 is already in place with tests? Does this define the point at which 3.0.0 gets released and everything else gets punted to 4.0.0? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: 2.5.0-rc-3
On Wed, 2018-05-23 at 00:28 +1000, Paul King wrote: > No plans to go to 18/19 model at this stage. > > If we push for an early 3.0, some of the breaking changes will have to be > deferred. > A very quick release after 3.0 could easily be a 3.1 if it was needed. > > The next major release (4.0) would be when we had tackled (a significant > chunk of) the remaining breaking changes. > I am not sure a very rapid 3.0 → 3.1 is actually any sort of problem per se. In the current climate is a 3.0 now, 4.0 in the next year actually a problem? Given the very volunteer nature of the Groovy project, pragmatism more than anything has to be the order of the day. However I think there is a marketing element here. Having new 2.4.X releases doesn't really achieve anything marketing-wise. Releasing 2.5.0 actually doesn't much either really, though clearly we do it as we are already at RC-3, and it can be "milked". But 2.5 is just backward compatible extensions to 2.4, is this Groovy actually progressing? I suggest we want to get a 3.0 out to show Groovy is progressing and with some breaking changes, in particular JDK8+ only, not to mention a parser based on somewhat newer technology! "Groovy drops support for JDK7" is probably a good thing marketing wise. My feeling is that Groovy does not have enough resource to go for big major version number releases, but that it needs something to combat the "it's old technology" feel given the rise of Kotlin. I'd push for a 3.0 release soon and worry about the metamodel changes later – unless they are already in place? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Groovy 2.5.0-rc-3 fails to break Gant [was Groovy 2.5.0-rc-2 breaks Gant]
Hi, All Gant master/HEAD tests pass with Groovy 2.5.0-rc-3. :-) -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: 2.5.0-rc-3
On Tue, 2018-05-22 at 15:06 +0200, mg wrote: > Is the intention to switch to a rapid major release cycle like Windows, > Java, etc ? If yes: Shouldn't we then call the next major release Groovy 18 > (or 19, depending on year of release) ? > Could also be: groovy 2.6 -> groovy 18.0groovy 3.0 -> groovy 19.0 > What exactly would be in 4.0 ? Going to 4.0 quickly after 3.0 seems to > devalue to me what an old school major release encompasses/means (with > regards to expectations/press coverage/etc)... (?) As I remember the various argument over the years, the resultant intention has always been for Groovy to have what is effectively semantic versioning. I quite like semantic versioning, I am not a fan of the current Java versioning system even though I can, sort of, understand why they went the route they have. To see why, you just have to look at the Linux 3 → 4 number change. -- Russel. ========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
On Sun, 2018-05-20 at 16:01 +0200, Cédric Champeau wrote: > +1 but alternatively, we could just skip 2.6 and go straight to 3.0. > The point here being should Groovy continue to support JDK7? I'd say no, people who insist on using JDK7 have Groovy 2.4.15, if they want Groovy 3.0.0then upgrade to JDK8. There ought to be a limit on pandering to those who will not upgrade. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [DISCUSS] Renumber Groovy 2.6 to 2.9
On Sun, 2018-05-20 at 13:58 +1000, Paul King wrote: > Hi, > > I was wondering what people thought about renumbering Groovy 2.6 to 2.9. > It is only a subtle change but I think better conveys that it isn't a small > step up > from 2.5 but rather something just a bit short of 3. > If it is to be the last 2.X release why not 2.99 to make it more "in your face"? -- Russel. ========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Groovy 2.5.0-rc-2 breaks Gant
On Fri, 2018-05-18 at 22:29 +0900, Remko Popma wrote: […] > Just out of interest, will Gant migrate to groovy.cli.commons.CliBuilder or > groovy.cli.picocli.CliBuilder? Well on the one hand, Gant is a dead project that no-one cares about. It hasn't had a release since Codehaus died, mainly because I can't work out how to get a release into Bintray/Artifactory/Maven Central – mostly because no- one uses Gant and do not actually care, so I don't work on it (*). On the other hand I do regularly build it just to see what is broken. Mostly just to be amazed at how broken it has become. Let's get 2.5.0-rc-3 out there and I might take a more serious look just for the hell of it. Gant is based on ancient Groovy and it's build on ancient Gradle, technically it all needs a significant rewrite, but Gant was a thing of 2006 to 2008 (**) so well past it's use by date – unless someone know differently. (*) Much of this also applies to GPars. (**) Because Gradle. Obviously. Gant lost it's raison d'etre when Hans and Adam started Gradle in late 2007. And good for Hans he did a great job. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.0-rc-3
> [ ] +1 Release Apache Groovy 2.5.0-rc-3 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.0-rc-3 because... > > +1 -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Support Java-like array
On Wed, 2018-05-16 at 23:17 +0200, MG wrote: > Thank you Jochen and Cédric for explaining you rationale. It is funny, > because I always thought keeping Groovy as close to Java as possible was > a given. Evidently it is not... > […] I 2003/2004 having a dynamic version of Java was great stuff. Also it allowed for less verbosity. Time has moved on as has Java (finally). And there is now Kotlin. Is the role of Groovy today to be the dynamic Java trying hard to have statically type bits, or is it to be its own language with its own evolutionary path? -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: What the... static compile by default
On Sat, 2018-05-12 at 06:08 -0700, Daniel.Sun wrote: > Hi Russel, > > Yep. Eye drops can relieve my pain. It have to take a bit long time to > recover... > Good that the drops deal with the pain. Relax as much as possible to make the recovery time as short as possible. -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: What the... static compile by default
On Fri, 2018-05-11 at 22:57 -0700, Daniel.Sun wrote: […] > > P.S. Recently I'm suffering from conjunctivitis... > Daniel, Hopefully medics have given you something to relieve the itching and pain, and that it clears up quickly. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Building Gant
) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) at java.base/java.lang.Thread.run(Thread.java:844) -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 3.0.0-alpha-2
> > [ ] +1 Release Apache Groovy 3.0.0-alpha-2 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 3.0.0-alpha-2 because... > +1 I base my vote not on the distribution, but on building master/HEAD, but this is an alpha release and the more we get people using 3.0.0 the better. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Master/HEAD doesn't build
Debian Sid, with OpenJDK10 > Configure project : ArtifactoryUser user: null Using Java from /usr/lib/jvm/java-10-openjdk-amd64 (version 10) Detected development environment [buildinfo] Properties file path was not found! (Relevant only for builds running on a CI Server) > Task :generateGrammarSource FAILED error(160): GroovyParser.g4:37:17: cannot find tokens file '/home/users/russel/Repositories/Git/Forks/Groovy/target/generated-src/antlr/main/GroovyLexer.tokens' warning(125): GroovyParser.g4:109:23: implicit definition of token 'PACKAGE' in parser warning(125): GroovyParser.g4:113:23: implicit definition of token 'IMPORT' in parser … -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
GroovyConsole colour scheme
Using Groovy master HEAD (well from a couple of days ago as master/HEAD won't compile just now) on Debian Sid with OpenJDK10 with GNOME "dark mode" on is presenting a problem. It used to be that GroovyConsole did not obey GTK+ themes it seems it does now. So now that it is dark all the colours lead to invisible code since colours that were good for "dark on white" are invisible for "light on dark". I have no idea how to fix this, but it will be a problem for anyone using dark GTK+. -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy and testing
Hi, With all the versions of Groovy currently released, there is a problem that anyone using Spock seems to be stuck on Groovy 2.4.x because the latest version of Spock is 1.1-groovy-2.4 and so there is no reliable Spock for Groovy 2.5.x, 2.6.x or 3.0.x. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Stop maintaining 2.4.x?
On Mon, 2018-03-12 at 18:02 +0100, Cédric Champeau wrote: > I don't think calling it 3.0-jdk7 is a good thing to do: the runtime > would > be different, with different bugs. Plus, it would add confusion on > some > build tools, with random dependencies on jdk7, or indy, or ... > > I think we should focus on getting 2.5 out, and then go with 3.0 > asap. The implication is to ignore Groovy 3.0.0 on JDK7. This sounds like A Very Good Idea™ -- Russel. =========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Stop maintaining 2.4.x?
On Mon, 2018-03-12 at 12:23 +1000, Paul King wrote: > 2.6 is just 3.0 backported to JDK7 (minus those features which don't > backport easily without a JVM8). > Most users should be skipping 2.6 and going straight to 3.0 which is > where > our focus should be ... soon. > 2.6 is meant to help people start moving towards Parrot who are stuck > on > JDK7. Given it has limitations > anyway, I wouldn't imagine we'd do anything more than a 2.6.0 release > - > unless other community > members contributed the PRs to advance it. > Sounds like it isn't a 2.6.0 at all then. Should it be called 3.0.0- jdk7 so as to reflect what it actually is? > > -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Stop maintaining 2.4.x?
On Sun, 2018-03-11 at 15:24 +, Russel Winder wrote: > […] > > Where does 2.6.x git into this? > […] s/git/fit/ > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Stop maintaining 2.4.x?
On Sun, 2018-03-11 at 15:12 +0100, Cédric Champeau wrote: > Hi folks, > > I'm wondering if it's reasonable to continue maintaining 2.4.x. We > have a > long standing 2.5 release waiting, as well as 2.6 and master. Given > the > number of maintainers we have, I feel it's just slowing us down, and > we > need to move forward. Honestly I'd be in favor of only maintaining 2 > branches: 2.5.x and 3.0.x. > > WDYT? Where does 2.6.x git into this? But yes having fewer maintained versions makes sense not just because it saves developer hassle, but it makes things clearer for users, to many of whom seem to think running ancient versions of things in the face of having better, newer, versions is acceptable. -- Russel. =========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GPars and versions of Groovy
On Tue, 2018-03-06 at 23:19 +0100, Jochen Theodorou wrote: > On 06.03.2018 16:51, Russel Winder wrote: > > Hi, > > > > Currently the GPars build system assumes one and only one version > > of > > Groovy. Currently we have four, most likely incompatible, versions > > of > > Groovy on the boil: 2.4.14, 2.5.0-beta-3, 2.6.0-alpha-3, 3.0.0- > > alpha-1. > > Should GPars be build specially for each version of Groovy? > > building for 2.4.14 is supposed to work for 2.5.0 and 2.6.0. If not > we > did most likely something wrong. 3.0.0 is a different issue, but > even > here the 2.4.14 may just work. > > bye jochen Experience with Gant (which I am using to fiddle to get data for application on GPars, not because Gant is relevant any more) indicates that 2.4, 2.5, and 2.6 seem to behave the same but 3.0 is quite different – which is entirely reasonable. However I am finding that 2.4.14 on JDK8 has some critical differences of XML processing behaviour and some other issues to 2.4.14 on JDK9. So JDK9 causes some parts of 2.4.14 to behave differently to 2.4.14 on JDK8. I guess this implies CI is not picking up these differences. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GPars and versions of Groovy
On Tue, 2018-03-06 at 20:15 +0100, Jim Northrop wrote: > Thanks to you for this - > > Does this mean that GPars will no longer work on JDK1.7 ? What is the > minimum jdk that we require for GPars, please ? > Thx > Jim > GPars 2.0 requires JDK8 or later. I am not interested in doing anything with any JDK earlier that JDK8, so unless someone other than me does something, GPars 1.X is now past end of life and unmaintained. -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Groovy 2.4.14 on JDK8 and JDK9
Would I be right thinking that groovy.xml.DOMBuilder.parse(reader).documentElement.toString running using 2.4.14 behaves weirdly on JDK9 compared to JDK8? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GPars and versions of Groovy
On Tue, 2018-03-06 at 16:43 +, Kerridge, Jon wrote: > Hi, Hi Jon, > I am having the same problems with the JCSP and GroovyJCSP libraries > as well! It has been a very long while since I created the JCSP-1.1-rc5 artefact and put it into Maven Central. I can't remember which Java I used to build it. I am not sure I still have the Git repository with all the changes I needed to create the artefact. > Currently I have compilations for 2.4.14 and 2.5.x For Gant (a now useless project except for GINT) I have a Gradle build that builds for whichever Groovy versions I choose. Currently I assume: 2.4: 2.4.14 2.5: 2.5.0-beta-3 2.6: 2.6.0-alpha-3 3.0: 3.0.0-alpha-1 except it doesn't build just now as I haven't upgraded the build to Gradle 4.6. I'll fix this. The core idea is to set Gradle to build multiple projects but all using the same source just with different dependencies. Naming is the big issue. I have gone with: gant_groovy2.4 gant_groovy2.5 gant_groovy2.6 gant_groovy3.0 > I am then coping with the various versions of Java as well J8, 9 10 > and 11 before the end of this year! I am assuming a JDK8 target even though I am using JDK9. I have not done this as yet, but I am guessing that my one-dimensional structure can be extended to two dimensions by changing the path to the JDK version. This I think would be an excellent extension of the build matrix. If we need to do for GPars what I did for Gant, it would be a good opportunity to revise that whole build, indeed start from scratch. The Gant build has the added complexity of being able to build against a locally installed Groovy (built from Groovy master/HEAD usually). -- Russel. ======= Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
GPars and versions of Groovy
Hi, Currently the GPars build system assumes one and only one version of Groovy. Currently we have four, most likely incompatible, versions of Groovy on the boil: 2.4.14, 2.5.0-beta-3, 2.6.0-alpha-3, 3.0.0-alpha-1. Should GPars be build specially for each version of Groovy? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Felicitations [was [VOTE] Release Groovy 2.6.0-alpha-3]
Guillaume, Don't overdo it, and get well soon. On Mon, 2018-03-05 at 14:33 +0100, Guillaume Laforge wrote: > Hi Daniel, > > I just built from sources and ran my usual smoke test (hello world > style), > and all was fine. > But I haven't tested your native lambda work, sorry (I'm sick & > travelling > at the same time, so don't have much time for now) -- Russel. =========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Java grammar
Groovy used to have a Java grammar but the one (actually five) discovered are all a decade old. Anyone know of a YACC (or one easily translatable to YACC) grammar for a recent version of Java? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Groovy 2.5.0-beta-3
+1 > > [ ] +1 Release Apache Groovy 2.5.0-beta-3 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.0-beta-3 because... > > Here is my vote: > > +1 (binding) -- Russel. =========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Parser version
On Thu, 2018-02-08 at 10:13 -0700, Daniel.Sun wrote: > Hi Russel, > > ANTLR-4 parser(i.e. the Parrot parser) is the default one for > master, > and ANTLR-2 parser is default for other branches. > > Cheers, > Daniel.Sun Strange. I am building master and there is definitely an ANTLR2 generation phase of the build. -- Russel. =========== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Parser version
Is the ANTLR-2 parser really still the default one for Git master/HEAD? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: About the native-lambda branch
On Fri, 2018-01-12 at 05:54 -0700, Daniel.Sun wrote: > […] > As you see, the latest implementation is to generate method for lambda > at the class generation stage, in addition new inner classes will be > generated for each lambda. > > […] I haven't read the code, I am reacting to the above paragraph a bit out of context. Nonetheless… The whole point of Java lambdas and use of invokedynamic is to avoid any classes at all, so the mention of using an inner class worries me. The anonymous inner class route was tried and rejected in favour of runtime code generation triggered via an ignoredynamic – I do not know the full details, hopefully I am not wrong. The point here is for me, Groovy should use the same strategy as Java for what is a Java feature. -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: GPars progress [was CC and build revision]
I have started a TODO wiki page at https://github.com/GPars/GPars/wiki/ TODO I'll try to refine it and make it less opaque, and to highlight so specific things to get done. People should feel free to chip in questions on the page to help in the refining process. -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: CC and build revision
Hi, > I second mg's sentiments: a high level list of items to complete for the > next version of GPars would be great. I would like to contribute if I can, > but I have no idea at this point the scope of work to be done. I guess starting a wiki page is the right thing then? I wrote most of it up in various emails on the GPars and Groovy Dev lists so it is easy to make if people think that the right way forward. -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
CC and build revision
Thanks to Cédric for his time spent revising the Groovy build system. It is now much easier and simpler to build Groovy HEAD. I guess I am now under pressure to get GPars 2 out so Groovy can have a JDK8+ compliant concurrency/parallelism system. Sadly though despite a few calls for help via email, no-one other than me actually seems to care enough to put some effort in, which has led to me not being as proactive as it would good to be – motivation dissipated. Is there organisation out there that depends on GPars that can allocate some development resource for me to work with? -- Russel. == Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build updates
On Mon, 2017-12-11 at 18:08 +0100, Cédric Champeau wrote: > I'm sure you meant 2s ;) https://scans.gradle.com/s/b22mn4x32o6uw No, definitely 14s |> ./gradlew installGroovy -x asciidoctor <-> 0% INITIALIZING [0s] > buildSrc > settings WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/russel/.gradle/wrapper/dists/gradle-4.4-bin/bgaq7vklkazwgxox0hdadxbvi/gradle-4.4/lib/groovy-all-2.4.12.jar) to method java.lang.Object.finalize() WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass Build cache is an incubating feature. enable warnings of further illegal reflective access operations > Configure project : ArtifactoryUser user: null Using Java from /usr/lib/jvm/java-9-openjdk-9.0.1.11-4.fc28.x86_64 (version 9.0.1) Detected development environment [buildinfo] Properties file path was not found! (Relevant only for builds running on a CI Server) BUILD SUCCESSFUL in 14s 141 actionable tasks: 2 executed, 139 up-to-date Publishing build scan... https://gradle.com/s/4h7pelmmknh5y > Regarding the process, I prefer to prepare pull requests on GitHub, have > them reviewed there, then merge on Apache Git. But we have no official > process. This works for me, I shall arrange accordingly. -- Russel. ========= Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build updates
Cédric, Amended build is Big F## Win™ From scratch build using: ./gradlew installGroovy -x asciidoctor on Azul JDK9 goes from 8 to 9 minutes to 6-ish minutes, and the subsequent (effectuvely null build) goes from 7 to 8 minutes down to about 15 seconds. This is huge. :-) :-) -- Russel. = Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build updates
The build still appears to use the old ANTLR 2 parser, is this right? I thought Groovy 3.0 was going with the new parser. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Gradle build updates
What is the official Groovy workflow these days, is the GitHub repository considered the repository to work with, and the Apache repository just the place from which distributions are made? Cedric, This question arises as I am just about to try out your new build set up. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 41 Buckmaster Road m:+44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
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 by now. > Rémi > > > On November 22, 2017 10:06:48 AM GMT+01:00, Russel Winder <russel@win > der.org.uk> 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, so it is time to cut loose > > > > > > > And now of course people will be using OpendJDK10 ;-) > -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
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 Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
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 system.) Also Groovy 3 still seems to be built twice, non-indy and indy. Isn't it time to decide and ditch one of the builds to save 3 minutes on the build? -- Russel. === Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Bash feature is Shell script
Looks to be working now. Thanks for fast fixing. On Thu, 2017-09-28 at 11:11 -0700, Daniel Sun wrote: > Hi Bahman, > > As you proposed, the scripts have been modified: > https://github.com/apache/groovy/commit/87c68fba3b599238d5c900d8eb18975074fa > 926d > > Please give it a try. > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Re: Bash feature is Shell script
On Thu, 2017-09-28 at 01:09 -0700, Daniel Sun wrote: > Hi Russel, > > I just tried to fix the issue: > https://github.com/apache/groovy/commit/28d2f6a5f34f44f524ffea0e44be70c3c6a5 > c24e > Please give it a try :-) Evolved, but unfortunately: |> groovy -version /home/users/russel/lib/JDK/groovy/bin/groovy: 283: test: unexpected operator WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/users/russel/lib/JDK/groovy/lib/groovy-3.0.0-SNAPSHOT.jar) to method java.lang.Object.finalize() WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Groovy Version: 3.0.0-SNAPSHOT JVM: 9.0.0.15 Vendor: Azul Systems, Inc. OS: Linux -- Russel. ====== Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Roadm: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk signature.asc Description: This is a digitally signed message part
Bash feature is Shell script
Because Gradle can't cope with executing on Zulu 9 :-( I have to run Gradle on Zulu 8, but I can still execute on Zulu 9, well except for Groovy :-(( It looks like someone is assuming /bin/sh is actually Bash in the launch scripts for groovy: |> groovy -version /home/users/russel/lib/JDK/groovy/bin/groovy: 281: /home/users/russel/lib/JDK/groovy/bin/groovy: [[: not found WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/home/users/russel/lib/JDK/groovy/lib/groovy-3.0.0-SNAPSHOT.jar) to method java.lang.Object.finalize() WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release Groovy Version: 3.0.0-SNAPSHOT JVM: 9.0.0.15 Vendor: Azul Systems, Inc. OS: Linux I am unsure whether to suggest switching to Bash for launch or ensuring no Bash features in the scripts. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Antlr dependencies
On Sun, 2017-09-24 at 20:41 +1000, Paul King wrote: > Hi Russel, I assume adding -Dgroovy.antlr4=true to enable the Parrot parser > doesn't help? Sorry, I have been away from Groovy – is that an option to the Groovy system build or to an application build. If the former then there is nothing I can do to test it for 2.6-alpha-1. If the latter then there must be some special incantation requires since: compileGroovy.options.compilerArgs = ['-Xlint', '-Dgroovy.antlr4=true'] causes an error. -- Russel. ===== Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Antlr dependencies
Hi, For a bit of a laugh, I decided to try running the Gant build against Groovy 2.5 beta 1, 2.6 akpha 1, and 3.0.0 SNAPSHOT as well as 2.4.12. 2.4.12 and 2.5 beta 1 both worked fine. 2.6 alpha 1 and 3.0.0 SNAPSHOT however both report: error: Bad service configuration file, or exception thrown while constructing Processor object: javax.annotation.processing.Processor: Provider org.antlr.v4.runtime.misc.RuleDependencyProcessor not found startup failed: This is on Debian Sid using Zulu-8 and Gradle 4.2. Interesting (or not), Gradle 4.2 will not run on Zulu-9 or OpenJDK-9 as packaged by Fedora. Ho hum. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Groovy using Graal
On Tue, 2017-09-05 at 10:44 +1000, Paul King wrote: > Sounds like it might be useful for Groovy 4+. > If the plan is for Groovy 3 to depend on JDK8 and Groovy 4 to depend on JDK9 then yes. However is there a need to be quite so conservative? Groovy has so often had "hacks" so a version of Groovy could make use of more recent JDKs and yet still work on "long past end of life" versions of JDK. In this vein Groovy 3 could have a JDK9 variant using Graal. This option would, I feel, be a good marketing line for Groovy. "Graal Groovy now not later." -- Russel. ========= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: trySetAccessible for Java 9
On Wed, 2017-07-05 at 18:28 +0200, Cédric Champeau wrote: > […] > Any suggestion? How about leave Groovy 2.x as a "can only build on JDK8", and put all effort for a JDK9 build on Groovy 3.x which, as I understand it requires JDK8 as a runtime. This would seem to minimise hassle and maximise forward-looking benefit. Unless I am missing something. -- Russel. ===== Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: Build failing
On Sat, 2017-06-17 at 09:44 +0200, Cédric Champeau wrote: > Yes, there are apparently quite a few glitches after the upgrade. OK, it's not just me then. Which is good. Sort of. > Dear community, please give me the strength to rewrite this whole > build. > Need to make it cleaner, it accumulated too many years of hacking, > inherited from the Ant era. Time to do some cleanup! I think we have a Maven build after the Ant one and before the Gradle one. I know, I started it. :-) Also there was the modular rewrite, which put some hacks in along with the JDK version stuff. If you can put in place an overall new architecture for a Gradle 4.0 build, and do an exemplar "module" then many of us can chip in doing the leg-work of all the other "modules". Also if there is a repository to clone and work in which is not the mainline, it can be cloned and builds tried. We are here to help, you are not alone. -- Russel. ========= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Build failing
I guess it is already known that the build fails with Gradle 4.0? > Task :docGDK Err: Error: Could not find or load main class org.codehaus.groovy.tools.DocGenerator FAILURE: Build failed with an exception. * Where: Script '/home/users/russel/Repositories/Git/Forks/Groovy/gradle/docs.gradle' line: 138 * What went wrong: Execution failed for task ':docGDK'. > Java returned: 1 * Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. BUILD FAILED in 5m 33s 118 actionable tasks: 118 executed Publishing build scan... https://gradle.com/s/dbgpbsyhhzjyi -- Russel. ===== Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Indy vs default build
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:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.0-alpha-1 (take 3)
> [ ] +1 Release Apache Groovy 2.5.0-alpha-1 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.0-alpha-1 because... Vote early, vote often: +1 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.0-alpha-1 (take 2)
I said +1 before, so +1 from me this time. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.5.0-alpha-1
> [ ] +1 Release Apache Groovy 2.5.0-alpha-1 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.5.0-alpha-1 because... Now that Git master/HEAD is 3.0.0, I think there must be a 2.5.0 release. Given this is marked alpha, I see no reason not to release. +1 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Maven coordinates going forward, PS
On Mon, 2017-03-27 at 15:59 +0100, Russel Winder wrote: > On Mon, 2017-03-27 at 23:57 +1000, Paul King wrote: > > […] > > discussion in the past that Apache Groovy might (should?) change > > the > > Maven coordinates to have group org.apache.groovy rather than > > org.codehaus.groovy. Previously we have spoken about not doing that > > before some major release point. The Groovy team is now interested > > in > > your feedback as to whether this new version might be the right > > time > > to make that change. Apologies, I pressed send before adding: I think moving to org.apache.groovy for Groovy 3 would be an excellent idea. Clearly it would also be a good idea to move all the packages from org.codehaus.groovy to org.apache.groovy, but that could be argued as change for the sake of it. However I would say no, Groovy should move forward not look back, and org.apache.groovy is the future. Groovy 3 would strike me as the time to do this. -- Russel. ========= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Maven coordinates going forward
On Mon, 2017-03-27 at 23:57 +1000, Paul King wrote: > Hi, it's still a little while away but we'll soon begin the work on > what will be called Groovy 3 or Groovy 4 - the exact version number > is > potentially up for further debate depending on how other upcoming > Parrot back port work pans out but we are not asking for feedback on > that right now. Some of us are already using Groovy 3.0.0. ;-) > This new version of Groovy will have the new Parrot parser merged. > We're also planning to require JDK8 and it might have some other > breaking changes depending on how things pan out. There has been > discussion in the past that Apache Groovy might (should?) change the > Maven coordinates to have group org.apache.groovy rather than > org.codehaus.groovy. Previously we have spoken about not doing that > before some major release point. The Groovy team is now interested in > your feedback as to whether this new version might be the right time > to make that change. I am all for requiring JDK8 for Groovy 3 *AND* getting rid of the build of two lots of artefacts. Either we go with indy or we don't, I sugegst that Groovy 3 is the right place to go with only indy and drop the previous stuff. If the indy codes are slower then we fix it. > Obviously, we'll need to publicise the change to make sure people can > find the new versions but we are particularly interested in feedback > on whether anyone would be adversely affected by such a change. > > Comments welcome, > I am always willing to make comments. Actions less likely. ;-) Well unless it is GPars and Gant anyway. -- Russel. ========= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [VOTE] Release Apache Groovy 2.4.10 (take 2)
> [ ] +1 Release Apache Groovy 2.4.10 > [ ] 0 I don't have a strong opinion about this, but I assume it's ok > [ ] -1 Do not release Apache Groovy 2.4.10 because... I am not going to be able to check anything in the timebox so technically must abstain. But otherwise I'd be +1. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
GPars 1, 2, and 3
Once JAXFinance and DevoxxUK are over I will (finally) be able to get back to progressing GPars 2.0 to releasability. I also have to release Gant to try and find out how to release via JCenter/Bintray/Artifactory, good knowledge for GPars. Something nearly got done in January but that effort fell at the last hurdle. I also note that JDK9 may have some features that require a rethink of some GPars implementation detail for a JDK and later specific GPars. cf. http://gee.cs.oswego.edu/dl/html/j9mm.html So the overall plot seems to be: GPars 1.X effectively abandoned GPars 2.x JDK8 and above only due 2017-07 GPars 3.x JDK9 and above in planning. It might be worth thinking about whether GPars has a real future since so few people seem to be interested in actively working on it. With Quasar (Parallel Universe thing not Quasar Framework) there is a fibers, actors, CSP framework with resources behind it. OK so no proper dataflow out of the box, but it could be added. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: release process
On Mon, 2017-01-30 at 21:32 +0100, Guillaume Laforge wrote: > That's indeed another approach. > But that would mean two close major releases with breaking changes. > Do you > think it'd be acceptable? Major releases are what breaking changes are for. Or did I mean that the other way around. Having voted YES in the VOTE, which seems to very quickly stop being a VOTE and turned into a debate, I would be happy with the alternate proposal (which is not an alternate fact) From Andres: - Groovy 2.5: integrates 1 and 2, to be released ASAP, we've been waiting for this for too long - Groovy 3.0: integrate 3, 4 and 5. The only version with necessary breaking changes (we have no choice here) From Jochen: no 2.5 - 3.0 with macro methods and Java7 and parrot - 4.0 java8 and jigsaw From Alessio: - 2.5 as Cédric proposed (so Java 7 + macros) - 3.0 with Java 8 and Parrot - 4.0 with Java 9 and Jigsaw? All of these work fine given they ignore the supposed new MOP of Groovy 3 :-) Remember the first number is always about breaking changes, so lets do it. Let's break stuff. Then people can put their things back together and make them better instead of just letting them rot. -- Russel. ===== Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: [VOTE] Apache Groovy Roadmap
On Tue, 2017-01-31 at 09:37 +0100, Cédric Champeau wrote: > […] > > - [ ] YES, I approve the roadmap above > - [ ] NO, I do not approve the roadmap abobe beause... > - [ ] I don't mind, or this goes beyond what I can think of > > This vote is open for 72h, ending 9:30am CET, on Feb 3rd, 2017. YES -- Russel. ===== Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: next releases
On Tue, 2017-01-17 at 10:04 +0100, Cédric Champeau wrote: > My take is simpler than this. If Parrot should be included in 2.5, > then > remove the old parser and use it. If it's for 3.0, then it should not > belong to the 2.5 beta, or it should be an external dependency > (possibly > tested by adding a jar manually). Agreed. Then the question is whether a new parser is a minor change or a major change and whether 2.4 → 2.5 is a minor change or a major change. The 2.5 build still creates jars and indy jars. Isn't it about time we settle this so there are only one set of jars in a build? -- Russel. ========= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
