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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>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 Developerhttp://www.gradle.org > >
