Luke Taylor wrote:
Hi all,
I have a plugin I have been using for some time for docbook
processing. In the past I've just built it using Intellij and dropped
the jars and dependencies into the gradle lib directory and added the
class to the plugin.properties file. This was working find with the
current 0.8 distro.
I decided (using the latest codebase) to try actually using gradle to
build it and install it in my local repository (~/.m2/repository).
That works OK, but when I try and add it as a dependency to the build
script I want to use it from, things go awry:
buildscript {
repositories {
mavenRepo urls: 'file:///Users/luke/.m2/repository'
mavenCentral();
}
dependencies {
classpath 'monkeymachine.gradle:gradle-docbook:0.1-SNAPSHOT'
}
}
usePlugin monkeymachine.gradle.DocbookPlugin
There seems to be a problem with resolving one the transient
dependencies of 'org.apache.xmlgraphics:fop:0...@jar' and gradle ends
up in a recursive call to
DefaultIvyReportConverter.getResolvedDependenciesForNode:
Looking at the poms, fop is declared as depending on batik-transcoder,
and batik-transcoder as depending on fop. Gradle doesn't seem to like
the cycle in the dependency graph. While it is arguably a bad idea to
have a cycle such as this, Gradle should still be able to deal with it.
Could you add a JIRA issue for this problem?
Some possible work arounds for this (none are really that good) :
- Use a module definition for declaring your plugin dependency:
buildScript {
repositories { ... }
dependencies {
classpath
module('monkeymachine.gradle:gradle-docbook:0.1-SNAPSHOT') {
dependency('org.apache.xmlgraphics:fop:0...@jar')
dependency('org.apache.xmlgraphics:xmlgraphics-commons:1....@jar')
... a flattened list of all the dependencies ...
}
}
}
- Copy all the jars somewhere on the filesystem and use them from there:
buildScript {
repositories { ... }
dependencies {
// Use the jars from some local directory
classpath fileTree(dir: 'some/dir', includes: ['*.jar']
}
}
- Change the build for your plugin jar to create a 'fat' jar that
contains all the dependencies.
java.lang.StackOverflowError: null
at
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.getConfiguration(DefaultModuleDescriptor.java:404)
[ivy-2.1.0-rc2.jar:2.1.0-rc2]
at
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor.getArtifacts(DefaultModuleDescriptor.java:442)
[ivy-2.1.0-rc2.jar:2.1.0-rc2]
at
org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:789)
[ivy-2.1.0-rc2.jar:2.1.0-rc2]
at
org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:740)
[ivy-2.1.0-rc2.jar:2.1.0-rc2]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.getArtifacts(DefaultIvyReportConverter.java:279)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.createResolvedDependency(DefaultIvyReportConverter.java:265)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.getResolvedDependenciesForNode(DefaultIvyReportConverter.java:120)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.getResolvedDependenciesForNode(DefaultIvyReportConverter.java:135)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.getResolvedDependenciesForNode(DefaultIvyReportConverter.java:135)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
at
org.gradle.api.internal.artifacts.ivyservice.DefaultIvyReportConverter.getResolvedDependenciesForNode(DefaultIvyReportConverter.java:135)
[gradle-core-0.9-20091203145759+0000.jar:0.9-20091203145759+0000]
Leaving aside this issue (which I haven't had time to track down the
cause of), I was wondering if there is an alternative recommended
approach for configuring plugins.
Not really. This is the recommended way, though there are things we
could do to make it less work. For example, in your case, we could make
the 'maven' plugin automatically add $userHome/.m2/repository and maven
central as repositories. And we have talked about inlining the
dependency definition into the usePlugin method. Then (assuming we've
fixed the cyclic dependency problem), your build script might look like
this:
usePlugin 'maven'
usePlugin 'monkeymachine.gradle:gradle-docbook:0.1-SNAPSHOT'
We've also talked about adding docbook support to Gradle, so I guess
that would simplify your build script too.
I noticed that the concept of "init scripts" has been introduced. Is
it possible to use one of these to setup a plugin and add its
dependency jars without having to tinker with the gradle distro if I
rebuild it or switch to another version?
You definitely shouldn't have to mess with the Gradle distribution.
Adding a plugin from an init script is possible, but is a bit more
complicated at this stage.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
