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 <[email protected]> wrote: > Hi Roshan, > > On Mon, Dec 14, 2009 at 9:23 AM, Roshan Dawrani < > [email protected]> wrote: > >> >> On Mon, Dec 14, 2009 at 12:49 PM, Russel Winder < >> [email protected]> 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 >
