Re: Gradle build updates
(PPS: Just to be clear: I did not use the Gradle build from IntelliJ but used the IntelliJ build system) Ursprüngliche Nachricht Von: mg <mg...@arscreat.com> Datum: 23.12.17 15:32 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou <blackd...@gmx.org> Betreff: Re: Gradle build updates PS: Latest improvements on the Gradle build sound great, of course, not to take anything away from that :-) Ursprüngliche Nachricht Von: mg <mg...@arscreat.com> Datum: 23.12.17 14:43 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou <blackd...@gmx.org> Betreff: Re: Gradle build updates Hi Jochen, when I worked with Paul on @AutoFinal I quickly switched to using IntelliJ for all things build & test, due to the much easier to use fine control of e.g. what test to execute ("rerun failed tests" :-) ) - and minimal rebuild, of course. I had assumed everyone does that, to not go nuts (and only uses Gradle at the end for the "official build check")... Cheers,mg Ursprüngliche Nachricht Von: Jochen Theodorou <blackd...@gmx.org> Datum: 23.12.17 13:13 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Gradle build updates hi all, is there an easy way to execute only the tests of the main module and not of any sub-module? I am asking because for development it was for me first stage to get the tests of the main module running and then the sub modules. Now that all tests of all modules are executed in parallel and thus main is executed in something similar to a single thread mode, I have to wait much much longer for the main tests to get to the point of failure. Because otherwise the build became effectively slower for me bye Jochen
Re: Gradle build updates
PS: Latest improvements on the Gradle build sound great, of course, not to take anything away from that :-) Ursprüngliche Nachricht Von: mg <mg...@arscreat.com> Datum: 23.12.17 14:43 (GMT+01:00) An: dev@groovy.apache.org Cc: Jochen Theodorou <blackd...@gmx.org> Betreff: Re: Gradle build updates Hi Jochen, when I worked with Paul on @AutoFinal I quickly switched to using IntelliJ for all things build & test, due to the much easier to use fine control of e.g. what test to execute ("rerun failed tests" :-) ) - and minimal rebuild, of course. I had assumed everyone does that, to not go nuts (and only uses Gradle at the end for the "official build check")... Cheers,mg Ursprüngliche Nachricht Von: Jochen Theodorou <blackd...@gmx.org> Datum: 23.12.17 13:13 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Gradle build updates hi all, is there an easy way to execute only the tests of the main module and not of any sub-module? I am asking because for development it was for me first stage to get the tests of the main module running and then the sub modules. Now that all tests of all modules are executed in parallel and thus main is executed in something similar to a single thread mode, I have to wait much much longer for the main tests to get to the point of failure. Because otherwise the build became effectively slower for me bye Jochen
Re: Gradle build updates
Hi Jochen, when I worked with Paul on @AutoFinal I quickly switched to using IntelliJ for all things build & test, due to the much easier to use fine control of e.g. what test to execute ("rerun failed tests" :-) ) - and minimal rebuild, of course. I had assumed everyone does that, to not go nuts (and only uses Gradle at the end for the "official build check")... Cheers,mg Ursprüngliche Nachricht Von: Jochen Theodorou <blackd...@gmx.org> Datum: 23.12.17 13:13 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Gradle build updates hi all, is there an easy way to execute only the tests of the main module and not of any sub-module? I am asking because for development it was for me first stage to get the tests of the main module running and then the sub modules. Now that all tests of all modules are executed in parallel and thus main is executed in something similar to a single thread mode, I have to wait much much longer for the main tests to get to the point of failure. Because otherwise the build became effectively slower for me bye Jochen
Re: Gradle build updates
On 23.12.2017 13:39, Cédric Champeau wrote: If you only want the tests in the main project, run :test ah, of course... that was, what slipped my mind! Does not save as much time as I would like, but that is of course because we have a huge amount of tests in the main module bye Jochen
Re: Gradle build updates
On 23.12.2017 13:14, Cédric Champeau wrote: Just run :subprojectname:test You did not read my mail completely. I do not want to run the tests in a subproject. I want to run the test that are *not* in any subproject... so to say :main:test. But of course that does not work. And I really do not want to -x every sub module. bye Jochen
Re: Gradle build updates
Just run :subprojectname:test Le 23 déc. 2017 1:13 PM, "Jochen Theodorou"a écrit : > hi all, > > is there an easy way to execute only the tests of the main module and not > of any sub-module? I am asking because for development it was for me first > stage to get the tests of the main module running and then the sub modules. > Now that all tests of all modules are executed in parallel and thus main is > executed in something similar to a single thread mode, I have to wait much > much longer for the main tests to get to the point of failure. Because > otherwise the build became effectively slower for me > > bye Jochen >
Re: Gradle build updates
hi all, is there an easy way to execute only the tests of the main module and not of any sub-module? I am asking because for development it was for me first stage to get the tests of the main module running and then the sub modules. Now that all tests of all modules are executed in parallel and thus main is executed in something similar to a single thread mode, I have to wait much much longer for the main tests to get to the point of failure. Because otherwise the build became effectively slower for me bye Jochen
Re: Gradle build updates
No there is not. But it should be pretty easy to do so, using Gradle shadow plugin for example. 2017-12-18 16:59 GMT+01:00: > "The "all" sources is still produced. But there's no all jar anymore." > > > > Is there a way to get back to being able to produce an all jar? I > actually leverage the embeddable jar for embedding in another OSGi bundle. > I was humming along with adding Groovy 2.5 support through beta2 and now it > seems I would have to retool my single jar handling to deal with a number > of module jars instead. >
RE: Gradle build updates
"The "all" sources is still produced. But there's no all jar anymore." Is there a way to get back to being able to produce an all jar? I actually leverage the embeddable jar for embedding in another OSGi bundle. I was humming along with adding Groovy 2.5 support through beta2 and now it seems I would have to retool my single jar handling to deal with a number of module jars instead.
Re: Gradle build updates
Amazing! The build of master costs only about 15 min now(about 25 min in the past). Cédric, you help us save a lot of time, thanks a lot! Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Alright folks, I have completed most of what I wanted to do. The performance of the build is now much better. I have backported everything to the 2.5 and 2.6 branches, and also updated CI. > So is it still possible to produce the groovy-all.jar and groovy-all-sources.jar from the SDK zip? The "all" sources is still produced. But there's no all jar anymore. 2017-12-13 17:53 GMT+01:00: > So is it still possible to produce the groovy-all.jar and > groovy-all-sources.jar from the SDK zip? >
RE: Gradle build updates
So is it still possible to produce the groovy-all.jar and groovy-all-sources.jar from the SDK zip?
Re: Gradle build updates
Fixed, thanks for reporting. > In addition, Groovy Version can not be shown properly(Groovy Version: > #ImplementationVersion#): > > C:\Users\Daniel>groovy -v > Groovy Version: #ImplementationVersion# JVM: 1.8.0_121 Vendor: Oracle > Corporation OS: Windows 10 > > > Cheers, > Daniel.Sun > > > > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: Gradle build updates
@Paul I only kept the `java7Compatible` checks to make it easier to backport changes. Each branch can now be adjusted as needed. 2017-12-13 7:35 GMT+01:00 Paul King: > Actually, it looks like you are still using skipIndy but why check for > java7Compatible when that is out minimum requirement anyway? > > On Wed, Dec 13, 2017 at 4:21 PM, Paul King wrote: > >> Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the >> build fails for me when I used an old commandline with -PskipIndy=true. >> >> Cheers, Paul. >> >> On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeau < >> cedric.champ...@gmail.com> wrote: >> >>> Hi folks, >>> >>> As promised I spent some time reworking the Gradle build. For those >>> interested, you can take a look at the progress checking out my branch [1]. >>> >>> You'll notice that the build should be much faster [2], especially after >>> changes, and it now makes use of the build cache. I also got rid of the >>> crazy way to build the indy jars, it's now streamlined. >>> >>> I'm interested in feedback, since it's a potential breaking change. If >>> everything goes well, I will backport the changes to the 2.5/2.6 builds (so >>> please avoid changes there too). >>> >>> Thanks a lot, >>> >>> [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle >>> [2] https://scans.gradle.com/s/msvk2xi57div2 >>> >> >> >
Re: Gradle build updates
Actually, it looks like you are still using skipIndy but why check for java7Compatible when that is out minimum requirement anyway? On Wed, Dec 13, 2017 at 4:21 PM, Paul Kingwrote: > Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the > build fails for me when I used an old commandline with -PskipIndy=true. > > Cheers, Paul. > > On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeau < > cedric.champ...@gmail.com> wrote: > >> Hi folks, >> >> As promised I spent some time reworking the Gradle build. For those >> interested, you can take a look at the progress checking out my branch [1]. >> >> You'll notice that the build should be much faster [2], especially after >> changes, and it now makes use of the build cache. I also got rid of the >> crazy way to build the indy jars, it's now streamlined. >> >> I'm interested in feedback, since it's a potential breaking change. If >> everything goes well, I will backport the changes to the 2.5/2.6 builds (so >> please avoid changes there too). >> >> Thanks a lot, >> >> [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle >> [2] https://scans.gradle.com/s/msvk2xi57div2 >> > >
Re: Gradle build updates
Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the build fails for me when I used an old commandline with -PskipIndy=true. Cheers, Paul. On Mon, Dec 11, 2017 at 9:54 AM, Cédric Champeauwrote: > Hi folks, > > As promised I spent some time reworking the Gradle build. For those > interested, you can take a look at the progress checking out my branch [1]. > > You'll notice that the build should be much faster [2], especially after > changes, and it now makes use of the build cache. I also got rid of the > crazy way to build the indy jars, it's now streamlined. > > I'm interested in feedback, since it's a potential breaking change. If > everything goes well, I will backport the changes to the 2.5/2.6 builds (so > please avoid changes there too). > > Thanks a lot, > > [1] https://github.com/melix/groovy-core/commits/cc/rebuild-gradle > [2] https://scans.gradle.com/s/msvk2xi57div2 >
Re: Gradle build updates
groovy-2.5.0-SNAPSHOT has the same trivial issue(".shelf"). In addition, Groovy Version can not be shown properly(Groovy Version: #ImplementationVersion#): C:\Users\Daniel>groovy -v Groovy Version: #ImplementationVersion# JVM: 1.8.0_121 Vendor: Oracle Corporation OS: Windows 10 Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Thank you, Cédric :) I tried to build from groovy-2.6.0-SNAPSHOT source code and found a trivial issue: apache-groovy-src-2.6.0-SNAPSHOT.zip file contains "groovy-2.6.0-SNAPSHOT/.shelf", which should be excluded IMO. Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: Gradle build updates
Alright folks, I have backported the changes to both 2.5.x and 2.6.x. Let me know if you see any problem. Note that I haven't changed the CI builds, but they probably need to, as there's no reason to differentiate the indy and non indy builds now. 2017-12-12 9:34 GMT+01:00 Daniel.Sun: > > I have pushed a proper fix. > The proper fix is much better :) > > Cheers, > Daniel.Sun > > > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >
Re: Gradle build updates
> I have pushed a proper fix. The proper fix is much better :) Cheers, Daniel.Sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
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.Sunwrote: > > 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 >
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: 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 Champeauwrote: > 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: 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.Sunwrote: > > > > 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: Gradle build updates
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.Sunwrote: > > 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: Gradle build updates
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