On Oct 13, 2008, at 11:59 AM, Peter Ledbrook wrote:
Here is an example here:
http://gradle.org/userguide/latest/masterch15.html#x51-13400015.3
See Javadoc:
http://gradle.org/api/0.4/org/gradle/api/
DependencyManager.html#antpath(java.lang.String)
That looks like just the ticket. Thanks Hans.
I'm running into problems here. I have this in the "dependencies"
closure:
dependencies {
addFlatDirResolver('lib', new File(rootDir, 'lib'))
clientModule(['groovy'], ":groovy-all:1.5.6") {
dependency(":commons-cli:1.0")
clientModule(":ant:1.7.0") {
dependencies(":ant-junit:1.7.0", ":ant-launcher:1.7.0")
}
}
...
}
and I'm using:
taskdef(name: "groovyc",
classname: "org.codehaus.groovy.ant.Groovyc",
classpath: dependencies.antpath("groovy"))
for the "groovyc" task. However, this only appears to be adding the
"groovy-all*" JAR to the classpath - the Ant libraries are not there.
<snip>
I have to admit I don't really understand how the client modules work,
but I would have thought that a dependency on "groovy-all*" would have
translated to the Ant libraries being included on the classpath. I
suspect I'm just misunderstanding what's supposed to be happening, so
any help would once again be greatly appreciated.
This is a feature. Gradle considers it as best practices that
transitive dependencies are not included in the compile classpath,
only in the runtime classpath. This feature is based internally on
Ivy, where you can declare whether a configuration should resolve
transitive dependencies or not. The 'groovy' and 'compile'
configuration are not transitive, the runtime configuration is. See
http://gradle.org/userguide/latest/masterch12.html#x35-7200012.1 for
why we think this is a good idea (although you can change this
behavior).
The normal Ivy/Maven way is the following. You declare a first level
dependency in your build script. To resolve this dependency a
repository is needed where Ivy/Maven look for an xml descriptor file
to learn about the transitive dependencies of this first level
dependency. You can go this way with Gradle as well. Depending on the
build, providing such an xml might be to much overhead. In particular
if you like to store the jars in svn. But how to tell Gradle what are
first level and what are transitive dependencies without having such
an xml descriptor? This is where client modules come into play. It is
an alternative to providing xml descriptors. In your case you declare
groovy as a first level dependency and the other stuff as transitive
dependencies. But the stuff you are compiling has Ant as a first
level dependency and we think this should be made expressive by
explicitly saying so.
I had a quick look at the grails build. I saw that you are already
using Ivy for dependency management. The repository you are working
against is the official Maven repo.
So simply saying:
dependencies {
addMavenRepo()
...
}
should give the exact behavior as with the current build. You would
not need client modules then (but you then depend on the often buggy
pom.xml in the Maven repo).
Simply saying:
dependencies {
groovy "org.codehaus.groovy:groovy-all:1.5.6"
}
does the job then. But as in the case above the transitive
dependencies are not in the returned list when saying
dependencies.antpath("groovy") or dependencies.antpath("compile").
You would need another line 'compile 'org.apache.ant:ant:1.7.0'
What I haven't understood in the current Grails iyvconf.xml is the
purpose of the "ibiblio-retry" resolver.
- Hans
Thanks,
Peter
--
Software Engineer
G2One, Inc.
http://www.g2one.com/
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
