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?
thanks,
Levi
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
