Luke, Thanks for your assistance with this.
As it turns out I could not reproduce it with your .zip either, so I started adding more to the gradle script until I got to my whole script and it still was fine! Then I started poking around in the fordeployment folder and saw that I had a groovy-all.1.5.7 jar in my fordeployments/lib folder, and I had been setting the classpath for the compileJava and compileGroovy to include **/*.jar from that folder. Removing that jar fixes the problem. I am assuming though that I ought to still leave the groovy jar on the compileJava classpath? I think it is needed since the .java code uses GroovyScriptEngine. Thanks! Levi On Jul 12, 2011, at 7:20 PM, Luke Daley <[email protected]> wrote: > I can't seem to reproduce this. > > Please see if you can configure the attached sample to exhibit the same > behaviour. I used 1.0-milestone-3 > > <groovy-compile-error-not-stopping.zip> > > On 13/07/2011, at 2:45 AM, Merlyn Albery-Speyer wrote: > >> That will do just fine, Levi. Now someone who knows the internals needs to >> weigh in. >> >> On Jul 12, 2011 9:30 AM, "Levi Yourchuck" <[email protected]> wrote: >> > Merlyn, >> > Here is a very concise example, not quite the absolute shortest >> > though.======================================package >> > levi.profiler.example;/** Tue Jul 12, 2011 Shows that the >> > gradle task 'compileGroovy' does not stop the build. (may be using >> > gradle wrong?)*/class UncompilableGroovyClass{ >> > ]}====================================== >> > When I do compileGroovy, this is output, but it proceeds and doesn't halt >> > the build. >> > ======================================:compileJavaNote: Some input files >> > use or override a deprecated API.Note: Recompile with -Xlint:deprecation >> > for details.Note: Some input files use unchecked or unsafe >> > operations.Note: Recompile with -Xlint:unchecked for >> > details.:compileGroovyorg.codehaus.groovy.control.MultipleCompilationErrorsException: >> > startup failed, >> > X:\_core\code\levi\profiler\example\UncompilableGroovyClass.groovy: 10: >> > unexpected token: ] @ line 10, column 2. ] ^ >> > 1 error====================================== >> > >> > The build.gradle file resides in the _core directory and I have done this >> > to account for not using the "main/java" folder >> > layout:======================================sourceSets { main { >> > java.srcDir 'code' resources.srcDir 'fordeployment' >> > groovy.srcDir 'code' }}====================================== >> > Any ideas? >> > thanks,Levi >> > >> > >> > >> > >> > __________________________________________ >> > >> > --- On Tue, 7/12/11, Merlyn Albery-Speyer >> > <[email protected]> wrote: >> > >> > From: Merlyn Albery-Speyer <[email protected]> >> > Subject: Re: [gradle-user] compileGroovy??? >> > To: [email protected] >> > Date: Tuesday, July 12, 2011, 10:33 AM >> > >> > Hi Levi, >> > Could you help by posting the smallest Groovy class that demonstrates this >> > issue? >> > Cheers, >> > >> > Merlyn >> > On Jul 12, 2011 4:03 AM, "Levi Yourchuck" <[email protected]> wrote: >> >> Hi all, >> >> I am wondering if this is the expected gradle behavior. >> > >> >> When I run the compileJava task and I have an error in the .java code, it >> >> will cause the gradle build to halt and not execute further tasks. >> >> However when I have an error in some .groovy code, it will cause an error >> >> in the console output similar to compileJava but it does not stop the >> >> gradle build. >> > >> >> This has the effect that when the jar task is chugging along, it does not >> >> have and .class files from a compileGroovy task to include and the >> >> subsequent build is broken but reports BUILD SUCCESSFUL. >> >> Is there something that I have to do when configuring the compileGroovy >> >> task in order to get this behavior? I am not seeing much for info on >> >> this in the docs. >> > >> >> thanks,Levi >> > > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com >
