Re: Gradle build updates

<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" :-) ) -

Re: Gradle build updates

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

Re: Gradle build updates

hat, 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

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

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

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

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

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

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

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 > > > > >

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

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 King wrote: > Should we just delete indy.gradle (obviously not in 2_4_X)? Otherwise the > build fails for

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 Champeau wrote: > Hi folks, > > As promised I spent some time

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,

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:

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

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

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:

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.

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

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 ;)

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, >

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. :-) :-) --

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

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.

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 -

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

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

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

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

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)

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 *

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 *

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

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 <

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

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: