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
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
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
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
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
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
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
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
"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
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
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
So is it still possible to produce the groovy-all.jar and
groovy-all-sources.jar from the SDK zip?
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
>
>
>
>
>
@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
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
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
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,
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:
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
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
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:
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
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.
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
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 ;)
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,
>
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.
:-) :-)
--
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
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.
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 -
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
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
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
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
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
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)
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
*
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
*
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
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 <
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
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:
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
44 matches
Mail list logo