Re: Gradle build updates

[mg]

(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

[mg]

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

[mg]

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

[Jochen Theodorou]

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

[Jochen Theodorou]

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

[Cédric Champeau]

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

[Jochen Theodorou]

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

[Cédric Champeau]

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

[eric.milles]

"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

[Daniel.Sun]

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

[Cédric Champeau]

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

[eric.milles]

So is it still possible to produce the groovy-all.jar and 
groovy-all-sources.jar from the SDK zip?

Re: Gradle build updates

[Cédric Champeau]

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

[Cédric Champeau]

@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

[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

[Paul King]

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

[Daniel.Sun]

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

[Daniel.Sun]

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

[Cédric Champeau]

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

[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

[Cédric Champeau]

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

[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/b607038002ead0459ae56a2a662793
> 859b3b9f51
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Gradle build updates

[Daniel.Sun]

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

[Daniel.Sun]

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

[Russel Winder]

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

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

[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

[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


signature.asc
Description: This is a digitally signed message part

Re: Gradle build updates

[Russel Winder]

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

[Russel Winder]

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

[Cédric Champeau]

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

[Cédric Champeau]

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

[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

[Daniel.Sun]

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

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

[Cédric Champeau]

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

[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

[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

[Daniel.Sun]

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

[Cédric Champeau]

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

[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/
> fb00a0465e378bc9070f1e7dec4550fb778812ae
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>

Re: Gradle build updates

[Jim Northrop]

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: Gradle build updates

[Daniel.Sun]

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

Gradle build updates

[Cédric Champeau]

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