Re: Gradle build updates
Thanks Daniel. Somehow the problem didn't happen to me locally, until I backported to 2.6 (not pushed yet, still have things that don't work properly on this branch). I have pushed a proper fix. 2017-12-12 6:41 GMT+01:00 Paul King : > Nice work guys! > > On Tue, Dec 12, 2017 at 3:39 PM, Daniel.Sun wrote: > >> >> The build works now :) >> https://github.com/apache/groovy/commit/b607038002ead0459ae5 >> 6a2a662793859b3b9f51 >> >> Cheers, >> Daniel.Sun >> >> >> >> -- >> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> > >
Re: Gradle build updates
Nice work guys! On Tue, Dec 12, 2017 at 3:39 PM, Daniel.Sun wrote: > > The build works now :) > https://github.com/apache/groovy/commit/b607038002ead0459ae56a2a662793 > 859b3b9f51 > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: Gradle build updates
The build works now :) https://github.com/apache/groovy/commit/b607038002ead0459ae56a2a662793859b3b9f51 Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Hi Cédric,
Even if some indy tests are excluded('Log4j2Test',
'ASTTransformationCustomizerTest'), the build still fails.
https://github.com/apache/groovy/commit/6d0c66773ba635db1c08f0575c7f901396fd2a4b
BTW, I found and fixed an invalid comment but it can not fix the
failing build.
https://github.com/apache/groovy/commit/392d3ac4b46bf872317fe77587c9cf0b9afd2194
I guess the classpath(`classpath = files(jar.archivePath)`) don't
contain groovy classes.
https://github.com/apache/groovy/blob/master/gradle/test.gradle#L137
Cheers,
Daniel.Sun
--
:compileTestExtensionModulewarning: [options] bootstrap class path not set
in conjunction with -source 1.6
/home/travis/build/apache/groovy/src/test-fixtures/extmodule/src/main/java/org/codehaus/groovy/runtime/m12n/Groovy7225Extension.java:21:
error: package groovy.lang does not exist
import groovy.lang.Closure;
^
/home/travis/build/apache/groovy/src/test-fixtures/extmodule/src/main/java/org/codehaus/groovy/runtime/m12n/Groovy7225Extension.java:28:
error: cannot find symbol
public static String groovy7225(Closure closure) {
^
symbol: class Closure
location: class Groovy7225Extension
2 errors
1 warning
FAILED
FAILURE: Build failed with an exception.
--
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
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
Ok I have merged the changes into master. One grey area is what will happen wrt to publishing to Bintray. Now the hard work starts: backporting the changes to 2.5/2.6. 2017-12-11 18:08 GMT+01:00 Cédric Champeau : > I'm sure you meant 2s ;) https://scans.gradle.com/s/b22mn4x32o6uw > > 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. > > 2017-12-11 17:01 GMT+01:00 Russel Winder : > >> 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 >> > >
Re: Gradle build updates
I'm sure you meant 2s ;) https://scans.gradle.com/s/b22mn4x32o6uw 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. 2017-12-11 17:01 GMT+01:00 Russel Winder : > 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 >
CI builds for Groovy
Has anyone noticed that there are 40+ pending changes waiting to build in TeamCity (Groovy 2.5) and no builds have run for several days? Same goes for 2.4, 2.6, 3.0. Eric Milles Lead Software Engineer Thomson Reuters Email: eric.mil...@thomsonreuters.com Phone: 651-848-7040
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: Functional interfaces and CompileStatic
Good job! -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Functional interfaces and CompileStatic
Nice! I'll check it tomorrow! :-)
On Mon, Dec 11, 2017 at 11:10 PM, Алексей Афанасьев
wrote:
> I've submitted pull request for this issue https://github.com/
> apache/groovy/pull/643 . There are at least two issues reported about
> this problem https://issues.apache.org/jira/browse/GROOVY-7061, h
> ttps://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-8241.
>
> 2017-12-08 10:55 GMT+03:00 Konstantin Boudnik :
>
>> Yup,
>>
>> Apache mailing lists do not accept attachments.
>> --
>> With regards,
>> Konstantin (Cos) Boudnik
>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>
>> Disclaimer: Opinions expressed in this email are those of the author,
>> and do not necessarily represent the views of any company the author
>> might be affiliated with at the moment of writing.
>>
>>
>> On Thu, Dec 7, 2017 at 10:39 PM, Nathan Harvey
>> wrote:
>> > Apologies, the mailing list removed my code (forum, anyone?). Here it
>> is:
>> >
>> > @CompileStatic
>> > class SampleClass {
>> > public void sample(Consumer consumer) {}
>> > public static void main(String[] args) {
>> > new SampleClass().sample({ String str ->
>> str.toUpperCase() }) // passes
>> > new SampleClass().sample({ it.toUpperCase() }) // passes
>> > new SampleClass().sample({ str -> it.toUpperCase() })
>> // fails
>> > }
>> > }
>> >
>> >
>> >
>> > --
>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
Re: Functional interfaces and CompileStatic
I've submitted pull request for this issue
https://github.com/apache/groovy/pull/643 . There are at least two issues
reported about this problem
https://issues.apache.org/jira/browse/GROOVY-7061,
https://issues.apache.org/jira/projects/GROOVY/issues/GROOVY-8241.
2017-12-08 10:55 GMT+03:00 Konstantin Boudnik :
> Yup,
>
> Apache mailing lists do not accept attachments.
> --
> With regards,
> Konstantin (Cos) Boudnik
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
>
> On Thu, Dec 7, 2017 at 10:39 PM, Nathan Harvey
> wrote:
> > Apologies, the mailing list removed my code (forum, anyone?). Here it is:
> >
> > @CompileStatic
> > class SampleClass {
> > public void sample(Consumer consumer) {}
> > public static void main(String[] args) {
> > new SampleClass().sample({ String str ->
> str.toUpperCase() }) // passes
> > new SampleClass().sample({ it.toUpperCase() }) // passes
> > new SampleClass().sample({ str -> it.toUpperCase() }) //
> fails
> > }
> > }
> >
> >
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: Gradle build updates
Thanks Paul, the SQL tests are now fixed. 2017-12-11 12:06 GMT+01:00 Paul King : > The Sql ones look like they are testing DataSets which require the source > files to be on the classpath. Sounds like the new setup isn't quite right > but I haven't dived into into yet - perhaps the old build was also wrong in > that regard. > > On Mon, Dec 11, 2017 at 8:23 PM, Cédric Champeau < > cedric.champ...@gmail.com> wrote: > >> BTW I have some tests failing with Indy: https://scans.gradle.com >> /s/5hluytiiafifk/tests/failed >> >> At this point I'm not sure if it's a problem with the new setup, or that >> it was uncaught before. >> >> 2017-12-11 11:10 GMT+01:00 Cédric Champeau : >> >>> Thanks Daniel. >>> >>> Would you mind trying again? I have fixed the problem I think. >>> >>> Also we now have a `testWithIndy` task, so a single build is capable of >>> testing both the normal and indy variants. >>> >>> 2017-12-11 10:22 GMT+01:00 Daniel.Sun : >>> 1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three groovy-raw-3.0.0-SNAPSHOT.jar with same size * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- corrected as the absolute path * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- corrected as the absolute path -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >>> >>> >> >
Re: Gradle build updates
Thanks! Found the problem. 2017-12-11 13:47 GMT+01:00 Daniel.Sun : > Hi Cédric, > > The following test failed because `-Dgroovy.attach.groovydoc=true` > is > missing > > :testWithIndyorg.apache.groovy.parser.antlr4.GroovyParserTest » test > groovy > core - Comments (0.702s) > java.lang.NullPointerException > : > Cannot get property 'content' on null object > Close stacktrace > at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:60) > at > org.codehaus.groovy.runtime.InvokerHelper.getProperty( > InvokerHelper.java:190) > at > org.codehaus.groovy.runtime.callsite.NullCallSite. > getProperty(NullCallSite.java:46) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty( > AbstractCallSite.java:299) > at > org.apache.groovy.parser.antlr4.GroovyParserTest.doTestAttachedComments( > GroovyParserTest.groovy:52) > at org.apache.groovy.parser.antlr4.GroovyParserTest.test groovy core - > Comments(GroovyParserTest.groovy:44) > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: Gradle build updates
Hi Cédric, The following test failed because `-Dgroovy.attach.groovydoc=true` is missing :testWithIndyorg.apache.groovy.parser.antlr4.GroovyParserTest » test groovy core - Comments (0.702s) java.lang.NullPointerException : Cannot get property 'content' on null object Close stacktrace at org.codehaus.groovy.runtime.NullObject.getProperty(NullObject.java:60) at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:190) at org.codehaus.groovy.runtime.callsite.NullCallSite.getProperty(NullCallSite.java:46) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:299) at org.apache.groovy.parser.antlr4.GroovyParserTest.doTestAttachedComments(GroovyParserTest.groovy:52) at org.apache.groovy.parser.antlr4.GroovyParserTest.test groovy core - Comments(GroovyParserTest.groovy:44) -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Hi Cédric, I built the distribution from the latest source code. The two issues are fixed :) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
The Sql ones look like they are testing DataSets which require the source files to be on the classpath. Sounds like the new setup isn't quite right but I haven't dived into into yet - perhaps the old build was also wrong in that regard. On Mon, Dec 11, 2017 at 8:23 PM, Cédric Champeau wrote: > BTW I have some tests failing with Indy: https://scans.gradle. > com/s/5hluytiiafifk/tests/failed > > At this point I'm not sure if it's a problem with the new setup, or that > it was uncaught before. > > 2017-12-11 11:10 GMT+01:00 Cédric Champeau : > >> Thanks Daniel. >> >> Would you mind trying again? I have fixed the problem I think. >> >> Also we now have a `testWithIndy` task, so a single build is capable of >> testing both the normal and indy variants. >> >> 2017-12-11 10:22 GMT+01:00 Daniel.Sun : >> >>> >>> 1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three >>> groovy-raw-3.0.0-SNAPSHOT.jar with same size >>> * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar >>> * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- >>> corrected >>> as the absolute path >>> * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- >>> corrected >>> as the absolute path >>> >>> >>> >>> >>> -- >>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >>> >> >> >
Re: Gradle build updates
BTW I have some tests failing with Indy: https://scans.gradle.com/s/5hluytiiafifk/tests/failed At this point I'm not sure if it's a problem with the new setup, or that it was uncaught before. 2017-12-11 11:10 GMT+01:00 Cédric Champeau : > Thanks Daniel. > > Would you mind trying again? I have fixed the problem I think. > > Also we now have a `testWithIndy` task, so a single build is capable of > testing both the normal and indy variants. > > 2017-12-11 10:22 GMT+01:00 Daniel.Sun : > >> >> 1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three >> groovy-raw-3.0.0-SNAPSHOT.jar with same size >> * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar >> * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- >> corrected >> as the absolute path >> * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- >> corrected >> as the absolute path >> >> >> >> >> -- >> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> > >
Re: Gradle build updates
Thanks Daniel. Would you mind trying again? I have fixed the problem I think. Also we now have a `testWithIndy` task, so a single build is capable of testing both the normal and indy variants. 2017-12-11 10:22 GMT+01:00 Daniel.Sun : > > 1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three > groovy-raw-3.0.0-SNAPSHOT.jar with same size > * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar > * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- > corrected > as the absolute path > * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- > corrected > as the absolute path > > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: Gradle build updates
1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three groovy-raw-3.0.0-SNAPSHOT.jar with same size * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- corrected as the absolute path * groovy-3.0.0-SNAPSHOT/lib/groovy-raw-3.0.0-SNAPSHOT.jar -- corrected as the absolute path -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Hi Cédric, I tried the distribution built from your fork and encountered the following issues: 1) apache-groovy-binary-3.0.0-SNAPSHOT.zip contains three groovy-raw-3.0.0-SNAPSHOT.jar with same size * groovy-3.0.0-SNAPSHOT/groovy-raw-3.0.0-SNAPSHOT.jar * lib/groovy-raw-3.0.0-SNAPSHOT.jar * lib/groovy-raw-3.0.0-SNAPSHOT.jar -- I'm not kidding... 2) commands fail to run C:\Users\Daniel>groovy -v java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:114) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:136) Caused by: java.lang.NoClassDefFoundError: org/objectweb/asm/Opcodes at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at org.codehaus.groovy.tools.RootLoader.oldFindClass(RootLoader.java:175) at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:147) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.codehaus.groovy.vmplugin.VMPluginFactory.(VMPluginFactory.java:39) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:118) at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.(MetaClassRegistryImpl.java:90) at groovy.lang.GroovySystem.(GroovySystem.java:36) at groovy.ui.GroovyMain.processArgs(GroovyMain.java:131) at groovy.ui.GroovyMain.main(GroovyMain.java:117) ... 6 more Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.Opcodes at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 24 more C:\Users\Daniel>groovyConsole java.lang.ClassNotFoundException: groovy.ui.Console at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:104) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:136) C:\Users\Daniel>groovySh java.lang.ClassNotFoundException: org.codehaus.groovy.tools.shell.Main at org.codehaus.groovy.tools.RootLoader.findClass(RootLoader.java:179) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at org.codehaus.groovy.tools.RootLoader.loadClass(RootLoader.java:151) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:104) at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:136) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [RESULT] [VOTE] Automatic module names
Great! The issue is gone. I tested on https://github.com/melix/groovy-core/commits/cc/rebuild-gradle Thank you, Cédric :-) -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
That's correct, the branch I have already does this. 2017-12-11 9:25 GMT+01:00 Paul King : > The idea (once finished) is that you can still depend on a groovy-all > dependency via Maven or Gradle and you'll automatically get the multiple > required equivalent jars of the current single groovy-all jar. > > Cheers, Paul. > > On Mon, Dec 11, 2017 at 5:31 PM, Jim Northrop < > james.b.north...@googlemail.com> wrote: > >> Good morning Cedric >> Wanted to ask if the removal of the jdk9 version of groovy-all jar will >> also mean that all us stuck on jdk1.7 will not have newer versions of >> groovy features? It would seem i would need to revise my gradles to include >> needed dependencies that groovy-all used to have but not now? >> Thanx Jim >> >> Sent from my iPad >> >> > On 11 Dec 2017, at 01:32, Daniel.Sun wrote: >> > >> > Hi Cédric, >> > >> > It looks fine to me. >> > >> > BTW, the following commit will break the build(my bad...), please >> > pull the latest code. >> > https://github.com/melix/groovy-core/commit/fb00a0465e378bc9 >> 070f1e7dec4550fb778812ae >> > >> > Cheers, >> > Daniel.Sun >> > >> > >> > >> > -- >> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> > >
Re: Gradle build updates
The idea (once finished) is that you can still depend on a groovy-all dependency via Maven or Gradle and you'll automatically get the multiple required equivalent jars of the current single groovy-all jar. Cheers, Paul. On Mon, Dec 11, 2017 at 5:31 PM, Jim Northrop < james.b.north...@googlemail.com> wrote: > Good morning Cedric > Wanted to ask if the removal of the jdk9 version of groovy-all jar will > also mean that all us stuck on jdk1.7 will not have newer versions of > groovy features? It would seem i would need to revise my gradles to include > needed dependencies that groovy-all used to have but not now? > Thanx Jim > > Sent from my iPad > > > On 11 Dec 2017, at 01:32, Daniel.Sun wrote: > > > > Hi Cédric, > > > > It looks fine to me. > > > > BTW, the following commit will break the build(my bad...), please > > pull the latest code. > > https://github.com/melix/groovy-core/commit/ > fb00a0465e378bc9070f1e7dec4550fb778812ae > > > > Cheers, > > Daniel.Sun > > > > > > > > -- > > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: [RESULT] [VOTE] Automatic module names
Nice. Let me test :) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [RESULT] [VOTE] Automatic module names
Maybe. You can already test :) 2017-12-11 8:43 GMT+01:00 Daniel Sun : > Hi Cédric, > > Out of curiosity, will the following issue be fixed too? > > "Execution failed for task ':clean' after gradle upgraded from 3.5.1 > to > 4.3.1"( https://github.com/gradle/gradle/issues/3437 ) > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
