Debugging the groovyc process forked by gradle?

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?

I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, Invalid commandline usage for
javac: invalid flag: -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777
Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
...
")

Thanks,
Roshan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Fwd: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Any gradle gurus around here - please help. Thanks.

---------- Forwarded message ----------
From: Roshan Dawrani <[hidden email]>
Date: Sun, Dec 13, 2009 at 2:38 PM
Subject: Debugging the groovyc process forked by gradle?
To: [hidden email]


Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?

I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, Invalid commandline usage for
javac: invalid flag: -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777
Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
...
")

Thanks,
Roshan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
In reply to this post by Roshan Dawrani-2
compileTestGroovy.options.compilerArgs = ['-Xlint'] seems to be working but the following, equivalent option doesn't work.

compileTestGroovy.options.compilerArgs = ['-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777']

Is the value '-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777' confusing gradle?


On Sun, Dec 13, 2009 at 2:38 PM, Roshan Dawrani <[hidden email]> wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?

I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, Invalid commandline usage for
javac: invalid flag: -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777
Usage: javac <options> <source files>
where possible options include:
  -g                         Generate all debugging info
...
")

Thanks,
Roshan

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: Debugging the groovyc process forked by gradle?

Russel Winder-2
On Sun, 2009-12-13 at 15:31 +0530, Roshan Dawrani wrote:

> compileTestGroovy.options.compilerArgs = ['-Xlint'] seems to be
> working but the following, equivalent option doesn't work.
>
> compileTestGroovy.options.compilerArgs =
> ['-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777']
>
> Is the value
> '-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777'
> confusing gradle?
>
It does look like a parsing/interpretation problem somewhere down the
chain, but Adam and Hans are the probably the best to comment on this.
However, as it is Sunday I suspect most folk round here will be taking
the day off.



--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Adam Murdoch-2
In reply to this post by Roshan Dawrani-2


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
> Hi,
> I need to look into one groovy issue and for that I need to debug the
> groovyc process that is forked by gradle.
>
> Could someone please let me know how to pass the compiler args in the
> gradle script to do the same?
>

Gradle uses Groovy's <groovyc> Ant task to do the compilation, and
looking at the source of this task, it doesn't look like it offers any
way to control the command-line args it uses to fork the groovyc
process. For Gradle to do what you're asking, it would need the Ant task
to support it first. Or for Gradle to drive Groovy's FileSystemCompiler
directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can
use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle
compileGroovy


> I tried
>
> compileTestGroovy.options.compilerArgs =
> [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]
>
> (fails with
> "org.codehaus.groovy.control.MultipleCompilationErrorsException:
> startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system
> cannot find the file specified)")
>
> and
>
> compileTestGroovy.options.compilerArgs =
> ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]
>

compilerArgs are passed directly to javac, by which time it's too late
for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Hi Adam,
Groovy's <groovyc> allows nested <compilerarg> elements (post GROOVY-3761), but that is available since 1.6.5, but the gradle snapshot that I am using uses 1.6.4.

My debugging sceario is this: GPARS uses gradle to compile its groovy scripts. While gradle internally uses 1.6.4, GPars compilation is done with 1.6.5 or say, even 1.7.0 (whatever is specified in its dependencies).GPars had a reported a very similar and that fix is there 1.6.5 onwards. So, it is important that the groovyc compilation that I want to debug doesn't have 1.6.4 from gradle's own internal classpath. I thought the forked groovyc will cleanly allow that.

Do you think that gradle's own classpath will not come into picture if I do "gradle compileGroovy" after setting GRADLE_OPTS? Will it cleanly have only GPars specified groovy jar (and not gradle's own) on the classpath if I do "gradle compileGroovy"?

rgds,
Roshan

On Mon, Dec 14, 2009 at 1:23 AM, Adam Murdoch <[hidden email]> wrote:


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?


Gradle uses Groovy's <groovyc> Ant task to do the compilation, and looking at the source of this task, it doesn't look like it offers any way to control the command-line args it uses to fork the groovyc process. For Gradle to do what you're asking, it would need the Ant task to support it first. Or for Gradle to drive Groovy's FileSystemCompiler directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle compileGroovy



I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]


compilerArgs are passed directly to javac, by which time it's too late for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
So, when gradle compiles GPars groovy scripts, at some point it will do

java org.codehaus.groovy.tools.FileSystemCompiler -cp "<classpath made of GPars specified dependecies including groovy 1.6.5+>" <GPars groovy sources to be compiled>

That is where I want to insert my debug settings -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777

Do you think it can be done in some way - with the groovy that gradle internally uses as of now?

Thanks,
Roshan

On Mon, Dec 14, 2009 at 6:50 AM, Roshan Dawrani <[hidden email]> wrote:
Hi Adam,
Groovy's <groovyc> allows nested <compilerarg> elements (post GROOVY-3761), but that is available since 1.6.5, but the gradle snapshot that I am using uses 1.6.4.

My debugging sceario is this: GPARS uses gradle to compile its groovy scripts. While gradle internally uses 1.6.4, GPars compilation is done with 1.6.5 or say, even 1.7.0 (whatever is specified in its dependencies).GPars had a reported a very similar and that fix is there 1.6.5 onwards. So, it is important that the groovyc compilation that I want to debug doesn't have 1.6.4 from gradle's own internal classpath. I thought the forked groovyc will cleanly allow that.

Do you think that gradle's own classpath will not come into picture if I do "gradle compileGroovy" after setting GRADLE_OPTS? Will it cleanly have only GPars specified groovy jar (and not gradle's own) on the classpath if I do "gradle compileGroovy"?

rgds,
Roshan


On Mon, Dec 14, 2009 at 1:23 AM, Adam Murdoch <[hidden email]> wrote:


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?


Gradle uses Groovy's <groovyc> Ant task to do the compilation, and looking at the source of this task, it doesn't look like it offers any way to control the command-line args it uses to fork the groovyc process. For Gradle to do what you're asking, it would need the Ant task to support it first. Or for Gradle to drive Groovy's FileSystemCompiler directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle compileGroovy



I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]


compilerArgs are passed directly to javac, by which time it's too late for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Adam Murdoch-2
In reply to this post by Roshan Dawrani-2


On 14/12/09 12:20 PM, Roshan Dawrani wrote:
Hi Adam,
Groovy's <groovyc> allows nested <compilerarg> elements (post GROOVY-3761), but that is available since 1.6.5, but the gradle snapshot that I am using uses 1.6.4.

My debugging sceario is this: GPARS uses gradle to compile its groovy scripts. While gradle internally uses 1.6.4, GPars compilation is done with 1.6.5 or say, even 1.7.0 (whatever is specified in its dependencies).GPars had a reported a very similar and that fix is there 1.6.5 onwards. So, it is important that the groovyc compilation that I want to debug doesn't have 1.6.4 from gradle's own internal classpath. I thought the forked groovyc will cleanly allow that.

Do you think that gradle's own classpath will not come into picture if I do "gradle compileGroovy" after setting GRADLE_OPTS? Will it cleanly have only GPars specified groovy jar (and not gradle's own) on the classpath if I do "gradle compileGroovy"?

Yes, that's how it's supposed to work. When we invoke <groovyc>, we load it in an isolated ClassLoader which doesn't include anything from Gradle's classpath. Of course, it's relatively complex code, so we may have broken something.


rgds,
Roshan

On Mon, Dec 14, 2009 at 1:23 AM, Adam Murdoch <[hidden email]> wrote:


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?


Gradle uses Groovy's <groovyc> Ant task to do the compilation, and looking at the source of this task, it doesn't look like it offers any way to control the command-line args it uses to fork the groovyc process. For Gradle to do what you're asking, it would need the Ant task to support it first. Or for Gradle to drive Groovy's FileSystemCompiler directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle compileGroovy



I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]


compilerArgs are passed directly to javac, by which time it's too late for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Adam Murdoch-2
In reply to this post by Roshan Dawrani-2


On 14/12/09 12:42 PM, Roshan Dawrani wrote:
So, when gradle compiles GPars groovy scripts, at some point it will do

java org.codehaus.groovy.tools.FileSystemCompiler -cp "<classpath made of GPars specified dependecies including groovy 1.6.5+>" <GPars groovy sources to be compiled>


Eventually, we will change Gradle to do this directly, maybe in the Gradle 0.10 release. But in the meantime, it does this indirectly by using the <groovyc> task. It uses the <groovyc> task from the version of Groovy specified in the dependencies, so in your case it should be using the <groovyc> task from Groovy 1.6.5

That is where I want to insert my debug settings -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777

Do you think it can be done in some way - with the groovy that gradle internally uses as of now?

Thanks,
Roshan

On Mon, Dec 14, 2009 at 6:50 AM, Roshan Dawrani <[hidden email]> wrote:
Hi Adam,
Groovy's <groovyc> allows nested <compilerarg> elements (post GROOVY-3761), but that is available since 1.6.5, but the gradle snapshot that I am using uses 1.6.4.

My debugging sceario is this: GPARS uses gradle to compile its groovy scripts. While gradle internally uses 1.6.4, GPars compilation is done with 1.6.5 or say, even 1.7.0 (whatever is specified in its dependencies).GPars had a reported a very similar and that fix is there 1.6.5 onwards. So, it is important that the groovyc compilation that I want to debug doesn't have 1.6.4 from gradle's own internal classpath. I thought the forked groovyc will cleanly allow that.

Do you think that gradle's own classpath will not come into picture if I do "gradle compileGroovy" after setting GRADLE_OPTS? Will it cleanly have only GPars specified groovy jar (and not gradle's own) on the classpath if I do "gradle compileGroovy"?

rgds,
Roshan


On Mon, Dec 14, 2009 at 1:23 AM, Adam Murdoch <[hidden email]> wrote:


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?


Gradle uses Groovy's <groovyc> Ant task to do the compilation, and looking at the source of this task, it doesn't look like it offers any way to control the command-line args it uses to fork the groovyc process. For Gradle to do what you're asking, it would need the Ant task to support it first. Or for Gradle to drive Groovy's FileSystemCompiler directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle compileGroovy



I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]


compilerArgs are passed directly to javac, by which time it's too late for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email





-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Is there a gradle version(snapshot?) available that uses groovy 1.6.5(+)? Or will I need to build it locally?

Or, do you think that just replacing 1.6.4 jar with 1.6.5 jar within current gradle\lib may work too?

Having a groovy 1.6.5 built gradle will also confirm whether the issue is due to some classloader mix-up in gradle or whether GPars issue exists even after having the fix for GROOVY-3761.


On Mon, Dec 14, 2009 at 7:24 AM, Adam Murdoch <[hidden email]> wrote:


On 14/12/09 12:42 PM, Roshan Dawrani wrote:
So, when gradle compiles GPars groovy scripts, at some point it will do

java org.codehaus.groovy.tools.FileSystemCompiler -cp "<classpath made of GPars specified dependecies including groovy 1.6.5+>" <GPars groovy sources to be compiled>


Eventually, we will change Gradle to do this directly, maybe in the Gradle 0.10 release. But in the meantime, it does this indirectly by using the <groovyc> task. It uses the <groovyc> task from the version of Groovy specified in the dependencies, so in your case it should be using the <groovyc> task from Groovy 1.6.5


That is where I want to insert my debug settings -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777

Do you think it can be done in some way - with the groovy that gradle internally uses as of now?

Thanks,
Roshan

On Mon, Dec 14, 2009 at 6:50 AM, Roshan Dawrani <[hidden email]> wrote:
Hi Adam,
Groovy's <groovyc> allows nested <compilerarg> elements (post GROOVY-3761), but that is available since 1.6.5, but the gradle snapshot that I am using uses 1.6.4.

My debugging sceario is this: GPARS uses gradle to compile its groovy scripts. While gradle internally uses 1.6.4, GPars compilation is done with 1.6.5 or say, even 1.7.0 (whatever is specified in its dependencies).GPars had a reported a very similar and that fix is there 1.6.5 onwards. So, it is important that the groovyc compilation that I want to debug doesn't have 1.6.4 from gradle's own internal classpath. I thought the forked groovyc will cleanly allow that.

Do you think that gradle's own classpath will not come into picture if I do "gradle compileGroovy" after setting GRADLE_OPTS? Will it cleanly have only GPars specified groovy jar (and not gradle's own) on the classpath if I do "gradle compileGroovy"?

rgds,
Roshan


On Mon, Dec 14, 2009 at 1:23 AM, Adam Murdoch <[hidden email]> wrote:


On 13/12/09 8:08 PM, Roshan Dawrani wrote:
Hi,
I need to look into one groovy issue and for that I need to debug the groovyc process that is forked by gradle.

Could someone please let me know how to pass the compiler args in the gradle script to do the same?


Gradle uses Groovy's <groovyc> Ant task to do the compilation, and looking at the source of this task, it doesn't look like it offers any way to control the command-line args it uses to fork the groovyc process. For Gradle to do what you're asking, it would need the Ant task to support it first. Or for Gradle to drive Groovy's FileSystemCompiler directly (which we plan to do eventually).

Any chance you can debug this problem in non-forking mode? Then, you can use $GRADLE_OPTS to pass the debug command-line options:

GRADLE_OPTS=-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777 gradle compileGroovy



I tried

compileTestGroovy.options.compilerArgs = [[value="-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]]

(fails with "org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, [-FXrunjdwp:transport=dt_sockeress=7777] (The system cannot find the file specified)")

and

compileTestGroovy.options.compilerArgs = ["-Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=7777"]


compilerArgs are passed directly to javac, by which time it's too late for you to any useful debugging (I suspect).


--
Adam Murdoch
Gradle Developer
http://www.gradle.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email





-- 
Adam Murdoch
Gradle Developer
http://www.gradle.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Russel Winder-2
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses groovy
> 1.6.5(+)? Or will I need to build it locally?

It seems there is an incompatibility between Gradle and all Groovy
versions post 1.6.4.  The sooner this is sorted and Gradle uses 1.6.7
the better.  Actually it would be even better if Gradle worked with
whichever version of Groovy the user nominated -- I for one want to use
Groovy 1.8-beta-1-SNAPSHOT.
>
> Or, do you think that just replacing 1.6.4 jar with 1.6.5 jar within
> current gradle\lib may work too?

Apparently this buggers up Gradle.
>
> Having a groovy 1.6.5 built gradle will also confirm whether the issue
> is due to some classloader mix-up in gradle or whether GPars issue
> exists even after having the fix for GROOVY-3761.



--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2

On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder <[hidden email]> wrote:
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses groovy
> 1.6.5(+)? Or will I need to build it locally?

It seems there is an incompatibility between Gradle and all Groovy
versions post 1.6.4.  The sooner this is sorted and Gradle uses 1.6.7
the better.

What kind of incompatibility? If I can't specify the remote debugging options with 1.6.4 that gradle has and also not be able to build it 1.6.5 due to some issues that u r hinting at, then I will hit a roadblock in my investigation of the issue that I wanted to do. I need to somehow debug the groovy compilation that gradle launches after forking it. :-(

rgds,
Roshan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Russel Winder-2
Roshan,

On Mon, 2009-12-14 at 13:53 +0530, Roshan Dawrani wrote:

>
> On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder
> <[hidden email]> wrote:
>         On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
>         > Is there a gradle version(snapshot?) available that uses
>         groovy
>         > 1.6.5(+)? Or will I need to build it locally?
>        
>        
>         It seems there is an incompatibility between Gradle and all
>         Groovy
>         versions post 1.6.4.  The sooner this is sorted and Gradle
>         uses 1.6.7
>         the better.
>
> What kind of incompatibility? If I can't specify the remote debugging
> options with 1.6.4 that gradle has and also not be able to build it
> 1.6.5 due to some issues that u r hinting at, then I will hit a
> roadblock in my investigation of the issue that I wanted to do. I need
> to somehow debug the groovy compilation that gradle launches after
> forking it. :-(
See http://docs.codehaus.org/pages/viewpage.action?pageId=135856154
there is a note about Groovy versions there.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Too little info there. I hope a bug was filed for that issue. If yes, I will interested in knowing which one.

I am all deviated from my original gradle need now for which I started this thread :-) Hope someone will help out with that.


On Mon, Dec 14, 2009 at 3:26 PM, Russel Winder <[hidden email]> wrote:
Roshan,

On Mon, 2009-12-14 at 13:53 +0530, Roshan Dawrani wrote:
>
> On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder
> <[hidden email]> wrote:
>         On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
>         > Is there a gradle version(snapshot?) available that uses
>         groovy
>         > 1.6.5(+)? Or will I need to build it locally?
>
>
>         It seems there is an incompatibility between Gradle and all
>         Groovy
>         versions post 1.6.4.  The sooner this is sorted and Gradle
>         uses 1.6.7
>         the better.
>
> What kind of incompatibility? If I can't specify the remote debugging
> options with 1.6.4 that gradle has and also not be able to build it
> 1.6.5 due to some issues that u r hinting at, then I will hit a
> roadblock in my investigation of the issue that I wanted to do. I need
> to somehow debug the groovy compilation that gradle launches after
> forking it. :-(

See http://docs.codehaus.org/pages/viewpage.action?pageId=135856154
there is a note about Groovy versions there.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

hans_d
Administrator
In reply to this post by Russel Winder-2


On Mon, Dec 14, 2009 at 8:19 AM, Russel Winder <[hidden email]> wrote:
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses groovy
> 1.6.5(+)? Or will I need to build it locally?

It seems there is an incompatibility between Gradle and all Groovy
versions post 1.6.4.  The sooner this is sorted and Gradle uses 1.6.7
the better.  Actually it would be even better if Gradle worked with
whichever version of Groovy the user nominated -- I for one want to use
Groovy 1.8-beta-1-SNAPSHOT.

I don't think this works out. It will be a maintainability nightmare. See Grails, where a particular versions also uses a particular version of Groovy, doesn't it?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
 
>
> Or, do you think that just replacing 1.6.4 jar with 1.6.5 jar within
> current gradle\lib may work too?

Apparently this buggers up Gradle.
>
> Having a groovy 1.6.5 built gradle will also confirm whether the issue
> is due to some classloader mix-up in gradle or whether GPars issue
> exists even after having the fix for GROOVY-3761.



--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

hans_d
Administrator
In reply to this post by Roshan Dawrani-2
Hi Roshan,

On Mon, Dec 14, 2009 at 9:23 AM, Roshan Dawrani <[hidden email]> wrote:

On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder <[hidden email]> wrote:
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses groovy
> 1.6.5(+)? Or will I need to build it locally?

It seems there is an incompatibility between Gradle and all Groovy
versions post 1.6.4.  The sooner this is sorted and Gradle uses 1.6.7
the better.

What kind of incompatibility? If I can't specify the remote debugging options with 1.6.4 that gradle has and also not be able to build it 1.6.5 due to some issues that u r hinting at, then I will hit a roadblock in my investigation of the issue that I wanted to do. I need to somehow debug the groovy compilation that gradle launches after forking it. :-(

Why does fork=false and using GRADLE_OPTS does not do the trick?

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Hi Hans,
I had tried GRADLE_OPTS and that does not work on the forked java process that <groovyc> launches.

I did not try to "not fork" because then I was not sure whether I will be getting gradle's classloader isolation or not.

I don't want gradle's own groovy 1.6.4 also to be on the classpath when I investigate the groovy issue that I want to. So if I say fork=false and then run GPars build (which wants to do it with 1.6.5), can you please confirm whether only groovy 1.6.5 will be on the classpath and not gradle's 1.6.4?

rgds,
Roshan

On Mon, Dec 14, 2009 at 4:10 PM, Hans Dockter <[hidden email]> wrote:
Hi Roshan,

On Mon, Dec 14, 2009 at 9:23 AM, Roshan Dawrani <[hidden email]> wrote:

On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder <[hidden email]> wrote:
On Mon, 2009-12-14 at 07:34 +0530, Roshan Dawrani wrote:
> Is there a gradle version(snapshot?) available that uses groovy
> 1.6.5(+)? Or will I need to build it locally?

It seems there is an incompatibility between Gradle and all Groovy
versions post 1.6.4.  The sooner this is sorted and Gradle uses 1.6.7
the better.

What kind of incompatibility? If I can't specify the remote debugging options with 1.6.4 that gradle has and also not be able to build it 1.6.5 due to some issues that u r hinting at, then I will hit a roadblock in my investigation of the issue that I wanted to do. I need to somehow debug the groovy compilation that gradle launches after forking it. :-(

Why does fork=false and using GRADLE_OPTS does not do the trick?


- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

hans_d
Administrator


On Mon, Dec 14, 2009 at 12:00 PM, Roshan Dawrani <[hidden email]> wrote:
Hi Hans,
I had tried GRADLE_OPTS and that does not work on the forked java process that <groovyc> launches.

I did not try to "not fork" because then I was not sure whether I will be getting gradle's classloader isolation or not.

The Gradle classloader isolation should work also in non forked mode. It would be a bug if not.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2

On Mon, Dec 14, 2009 at 4:34 PM, Hans Dockter <[hidden email]> wrote:


On Mon, Dec 14, 2009 at 12:00 PM, Roshan Dawrani <[hidden email]> wrote:
Hi Hans,
I had tried GRADLE_OPTS and that does not work on the forked java process that <groovyc> launches.

I did not try to "not fork" because then I was not sure whether I will be getting gradle's classloader isolation or not.

The Gradle classloader isolation should work also in non forked mode. It would be a bug if not.


Ok, I will go ahead based on that then. Could you please point me into gradle codebase where it uses <groovyc> and launches the groovy compilation based on the dependencies of the project it is doing the build in?

If using fork=false does not work out, I would like to look in that area before raising it here again? Some pointers to where I should look will be helpful.

Thanks for your help.


- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Debugging the groovyc process forked by gradle?

Roshan Dawrani-2
Also it will be nice if you could let me know if a JIRA has been raised (and if yes, which one?) for the issue that is coming in way of gradle adopting a groovy newer than 1.6.4 (as noted in http://docs.codehaus.org/pages/viewpage.action?pageId=135856154).

rgds,
Roshan

On Mon, Dec 14, 2009 at 4:39 PM, Roshan Dawrani <[hidden email]> wrote:

On Mon, Dec 14, 2009 at 4:34 PM, Hans Dockter <[hidden email]> wrote:


On Mon, Dec 14, 2009 at 12:00 PM, Roshan Dawrani <[hidden email]> wrote:
Hi Hans,
I had tried GRADLE_OPTS and that does not work on the forked java process that <groovyc> launches.

I did not try to "not fork" because then I was not sure whether I will be getting gradle's classloader isolation or not.

The Gradle classloader isolation should work also in non forked mode. It would be a bug if not.


Ok, I will go ahead based on that then. Could you please point me into gradle codebase where it uses <groovyc> and launches the groovy compilation based on the dependencies of the project it is doing the build in?

If using fork=false does not work out, I would like to look in that area before raising it here again? Some pointers to where I should look will be helpful.

Thanks for your help.


- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org



12
Loading...