On Sat, 2016-07-16 at 19:31 +0100, Russel Winder wrote:
[…]
> I find that:
>
> ./gradlew clean && ./gradlew --parallel install
The --parallel is not the problem here, it behaves the same without it.
> results in an error very early on:
>
> …
> :compileJava
> warning: [options] bootstrap class
On Fri, 2016-07-15 at 17:12 +0200, Cédric Champeau wrote:
>
[…]
> I'm just doing this:
>
> JAVA_HOME=/opt/jdk1.9.0-jigsaw gw -Dscan --continue --parallel test
>
> Are you sure you are using the jigsaw build of JDK 9?
I find that:
./gradlew clean && ./gradlew --parallel install
results in an e
On 15.07.2016 21:54, Jochen Theodorou wrote:
On 15.07.2016 16:20, Cédric Champeau wrote:
[...]
Our build is still not fully Jigsaw compatible, there are still a
significant number of errors, including spurious classloading issues:
https://scans.gradle.com/s/jaefpwpny743e
So after fidling aroun
On 15.07.2016 16:20, Cédric Champeau wrote:
[...]
Our build is still not fully Jigsaw compatible, there are still a
significant number of errors, including spurious classloading issues:
https://scans.gradle.com/s/jaefpwpny743e
So after fidling around, with "--continue --parallel clean test -x
On 15.07.2016 17:56, Jochen Theodorou wrote:
[...]
> BUG! exception in phase 'class generation' in source unit
'/home/blackdrag/coding/groovy/commit/src/main/groovy/util/CliBuilder.groovy'
unsupported Target MODULE
actually I think that annotation target is not yet fixed and still in
discussi
On 15.07.2016 19:18, Cédric Champeau wrote:
Could it be related to your startup option?
XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
no, still getting that
bye Jochen
Could it be related to your startup option? XaddExports:jdk.compiler/com.s
un.tools.javac.api=ALL-UNNAMED
2016-07-15 17:56 GMT+02:00 Jochen Theodorou :
> ./gradlew -Dscan clean test
>
> gives me btw this result https://scans.gradle.com/s/3szt742ieifo6
>
> > BUG! exception in phase 'class generati
You can use different init scripts, but you wouldn't influence the gradle
opts variable.
2016-07-15 17:52 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:50, Cédric Champeau wrote:
>
>> Yeah, I found why it passed in my local build: my
>> ~/.gradle/gradle.properties file has higher priority.
>>
>
./gradlew -Dscan clean test
gives me btw this result https://scans.gradle.com/s/3szt742ieifo6
> BUG! exception in phase 'class generation' in source unit
'/home/blackdrag/coding/groovy/commit/src/main/groovy/util/CliBuilder.groovy'
unsupported Target MODULE
and true, we will need that new an
On 15.07.2016 17:50, Cédric Champeau wrote:
Yeah, I found why it passed in my local build: my
~/.gradle/gradle.properties file has higher priority.
does gradle offer a way to use multiple properties files? like for one
build this configuration and for another build another?
bye Jochen
Yeah, I found why it passed in my local build: my
~/.gradle/gradle.properties file has higher priority.
2016-07-15 17:45 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:34, Cédric Champeau wrote:
>
>> Can you try removing the `-XX:MaxPermSize=384m` option from
>> `gradle.properties` before runnin
On 15.07.2016 17:34, Cédric Champeau wrote:
Can you try removing the `-XX:MaxPermSize=384m` option from
`gradle.properties` before running (with the wrapper)?
my old configuration was
org.gradle.jvmargs=-ea -Xmx1G
XaddExports:jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED
which I am going
Can you try removing the `-XX:MaxPermSize=384m` option from
`gradle.properties` before running (with the wrapper)?
I'm not sure why I don't need to do it...
2016-07-15 17:18 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:17, Jochen Theodorou wrote:
>
>> On 15.07.2016 17:12, Cédric Champeau wrot
Are you running with the wrapper?
./gradlew ...
2016-07-15 17:18 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:17, Jochen Theodorou wrote:
>
>> On 15.07.2016 17:12, Cédric Champeau wrote:
>> [...]
>>
>>> I'm just doing this:
>>>
>>> JAVA_HOME=/opt/jdk1.9.0-jigsaw gw -Dscan --continue --paralle
It generates a build scan, so that you can share the results (exceptions,
environment, build log, ...) independently of where the build is done. See
scans.gradle.com
2016-07-15 17:17 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 17:12, Cédric Champeau wrote:
> [...]
>
>> I'm just doing this:
>>
>>
On 15.07.2016 17:17, Jochen Theodorou wrote:
On 15.07.2016 17:12, Cédric Champeau wrote:
[...]
I'm just doing this:
JAVA_HOME=/opt/jdk1.9.0-jigsaw gw -Dscan --continue --parallel test
Unrecognized VM option 'MaxPermSize=384m'
Error: Could not create the Java Virtual Machine.
Error: A fatal e
2016-07-15 17:10 GMT+02:00 Jochen Theodorou :
> On 15.07.2016 16:20, Cédric Champeau wrote:
>
>> So I managed to get the `groovy-xml` module build pass and test with
>> Jigsaw. It requires the latest snapshot of Gradle, and confirms that
>> using `-release` instead of {`-source`, `-target`, `-addm
On 15.07.2016 17:12, Cédric Champeau wrote:
[...]
I'm just doing this:
JAVA_HOME=/opt/jdk1.9.0-jigsaw gw -Dscan --continue --parallel test
Are you sure you are using the jigsaw build of JDK 9?
I am using build 9-ea+126-jigsaw-nightly-h5280-20160713, so yes.
What does -Dscan do?
bye Jochen
On 15.07.2016 16:20, Cédric Champeau wrote:
So I managed to get the `groovy-xml` module build pass and test with
Jigsaw. It requires the latest snapshot of Gradle, and confirms that
using `-release` instead of {`-source`, `-target`, `-addmods`} work.
There's a big drawback with using `-release` t
On Fri, 2016-07-15 at 16:20 +0200, Cédric Champeau wrote:
> So I managed to get the `groovy-xml` module build pass and test with
> Jigsaw. It requires the latest snapshot of Gradle, and confirms that
> using
> `-release` instead of {`-source`, `-target`, `-addmods`} work.
> There's a
> big drawback
oading issues:
https://scans.gradle.com/s/jaefpwpny743e
2016-07-09 10:27 GMT+02:00 Jochen Theodorou :
> On 09.07.2016 09:03, Remi Forax wrote:
>
>>
>>
>> - Mail original -
>>
>>> De: "Jochen Theodorou"
>>> À: dev@groovy.apache.org
&
On 09.07.2016 09:03, Remi Forax wrote:
- Mail original -
De: "Jochen Theodorou"
À: dev@groovy.apache.org
Envoyé: Vendredi 8 Juillet 2016 21:51:18
Objet: Re: JDK 9 Jigsaw builds
actually, I think I did see somewhere that JDK9 will support only 8 and
7 as targets. Maybe s
- Mail original -
> De: "Jochen Theodorou"
> À: dev@groovy.apache.org
> Envoyé: Vendredi 8 Juillet 2016 21:51:18
> Objet: Re: JDK 9 Jigsaw builds
>
> actually, I think I did see somewhere that JDK9 will support only 8 and
> 7 as targets. Maybe someon
actually, I think I did see somewhere that JDK9 will support only 8 and
7 as targets. Maybe someone can confirm that.
On 08.07.2016 17:44, Cédric Champeau wrote:
So I have patched the build to add the correct compile options for
`javac` in case JDK 9 is detected [1]. As the commit message state
Cedric, you should put that on the jigsaw list, they hear such problems
now more than before.
On 08.07.2016 17:44, Cédric Champeau wrote:
So I have patched the build to add the correct compile options for
`javac` in case JDK 9 is detected [1]. As the commit message states,
groovy-xml compile ge
With the following changes to commit 380ae614 I am able to successfully run
./gradlew :groovy-xml:test and ./gradlew :groovy-templates:test (with all
tests passing)
https://github.com/jwagenleitner/groovy/commit/3d3af66e7baf6a5b6ecfc063557f7aaf95a9b38a
There's probably a more efficient way to do
So I have patched the build to add the correct compile options for `javac`
in case JDK 9 is detected [1]. As the commit message states, groovy-xml
compile gets past compileJava, which is great, but then gets blocked by
groovyc, which doesn't see the javax.xml classes. This seems like a pretty
serio
On Fri, Jul 8, 2016 at 6:58 AM, Russel Winder wrote:
> On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote:
> > Turns out it is not a Groovy or Gradle thing, it seems the Java
> > executable doesn't like the options it advertises it responds to.
> >
> > > > (export _JAVA_OPTIONS="-addmods java
On Fri, 2016-07-08 at 14:34 +0100, Russel Winder wrote:
> Turns out it is not a Groovy or Gradle thing, it seems the Java
> executable doesn't like the options it advertises it responds to.
>
> > > (export _JAVA_OPTIONS="-addmods java.xml.bind"
> > > && /home/users/russel/lib.Linux.x86_64/JDK9/bi
Turns out it is not a Groovy or Gradle thing, it seems the Java
executable doesn't like the options it advertises it responds to.
|> (export _JAVA_OPTIONS="-addmods java.xml.bind" &&
/home/users/russel/lib.Linux.x86_64/JDK9/bin/java -version)
Unrecognized option: -addmods
Error: Could not create
On Fri, 2016-07-08 at 11:14 +0100, Russel Winder wrote:
> On Thu, 2016-07-07 at 13:28 +0200, Cédric Champeau wrote:
> > The option is `-addmods java.xml.bind`
> >
> >
>
> That doesn't work either :-(
>
> Unrecognized option: -addmods
> Error: Could not create the Java Virtual Machine.
> Error:
On Thu, 2016-07-07 at 13:28 +0200, Cédric Champeau wrote:
> The option is `-addmods java.xml.bind`
>
>
That doesn't work either :-(
Unrecognized option: -addmods
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
--
Russel.
===
The option is `-addmods java.xml.bind`
2016-07-07 12:56 GMT+02:00 Russel Winder :
> On Thu, 2016-07-07 at 07:44 +0200, Jochen Theodorou wrote:
> > On 06.07.2016 20:00, John Wagenleitner wrote:
> > > [...]In order to get the latest
> > > jdk-9 snapshot build to run locally I added the following ex
On Wed, 2016-07-06 at 11:00 -0700, John Wagenleitner wrote:
> Since the java.xml.bind module is no longer resolved by default (it's
> now
> part of the java.se.ee group) it must be explicitly added to the list
> of
> modules in order for the :groovy-xml:compileGroovy task to
> complete. In
> order
On Thu, 2016-07-07 at 07:44 +0200, Jochen Theodorou wrote:
> On 06.07.2016 20:00, John Wagenleitner wrote:
> > [...]In order to get the latest
> > jdk-9 snapshot build to run locally I added the following export.
> >
> > export _JAVA_OPTIONS="-Djdk.launcher.addmods=java.xml.bind"
>
> export _JAVA
On 06.07.2016 20:00, John Wagenleitner wrote:
[...]In order to get the latest
jdk-9 snapshot build to run locally I added the following export.
export _JAVA_OPTIONS="-Djdk.launcher.addmods=java.xml.bind"
export _JAVA_OPTIONS="--add-modules=javax.xml.bind"
does not work?
bye Jochen
Since the java.xml.bind module is no longer resolved by default (it's now
part of the java.se.ee group) it must be explicitly added to the list of
modules in order for the :groovy-xml:compileGroovy task to complete. In
order to get the latest jdk-9 snapshot build to run locally I added the
followi
37 matches
Mail list logo