On 13/07/2011, at 12:25 PM, Levi Yourchuck wrote: > On Jul 12, 2011, at 8:52 PM, Luke Daley <[email protected]> wrote: > >> >> On 13/07/2011, at 11:59 AM, Levi Yourchuck wrote: >> >>> 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. >> >> Is there any reason you are doing this rather than using Gradle's dependency >> management features? That's also a *very* old version of Groovy. >> > The main reason is that I just started using gradle two days ago. > I have converted some ant builds to gradle and have not read up on how to do > the dependency management with gradle. > > I am using groovy 1.8.0, hopefully I don't have a bunch of 'corrections' to > make now that I've purged that .jar. It was shocking. > >>> 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. >> >> Correct, but you should prefer using external dependency management instead >> of embedding the jar in your build. >> > I can see that a .jar folder has drawbacks. > Is there a particular external dependency management tool that gradle works > especially well with?
It will work with almost anything, but if you want to run up your own m2 format repository manager I'd suggest Artifactory. http://www.jfrog.com/ If you just want the Groovy jar though, you could simply pull it down from Maven Central. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
