Gradle provides the Java Servlet API and JSP API JARs in the
<Gradle-home>/lib/plugins directory by default. Both libraries are required
to run the Jetty plugin. BTW: I don't quite like this and hope that Gradle
will require plugins to define their dependencies in the future. They should
only pulled into the classpath when a plugin is applied. When using the
Tomcat plugin other versions of the libraries are required to be used
depending on the Tomcat version. Tomcat doesn't like having multiple
versions of these libraries in its classpath. An exception is thrown if this
happens. The user sets the embedded Tomcat libaries in the
buildscript|dependencies closure.
To make sure this conflict doesn't occur I create my own ClassLoader (it
excludes the plugin libraries for example) and set it as context ClassLoader
which is being used in the class TomcatServerFactory.
This works all great if you have separate build.gradle files in a
multi-module project. However, Alan reports that he uses just one
build.gradle for a multi-module project and then one of the plugin classes
cannot be found even though they are in the plugin JAR file. This is an
example how we set the plugin and its dependencies:
buildscript {
repositories {
add(new org.apache.ivy.plugins.resolver.URLResolver()) {
name = "GitHub"
addArtifactPattern
'http://cloud.github.com/downloads/bmuschko/gradle-tomcat-plugin/[module]-[revision].[ext]'
}
mavenCentral()
}
dependencies {
def tomcatVersion = '6.0.29'
classpath "org.apache.tomcat:catalina:${tomcatVersion}",
"org.apache.tomcat:coyote:${tomcatVersion}",
"org.apache.tomcat:jasper:${tomcatVersion}"
classpath ':gradle-tomcat-plugin:0.7'
}
}
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Classpath-differences-in-sub-project-build-gradle-files-tp4426268p4440045.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
