On 19/11/2010, at 1:18 AM, richardm wrote:
>
> As posted previously, using the following to create an ear file I get the war
> file included but nothing else (the jars on the classpath are not being
> added).
>
> task ear(dependsOn: 'war', type: Zip) {
> archiveName = 'myApp.ear'
> from war.archivePath
> // include the jars from the runtime classpath
> from sourceSets.main.runtimeClasspath.collect { it.isFile() }
> }
>
There are a couple of potential reasons why there may be no jars added:
The runtimeClasspath collection may be empty if none of the dependencies have
been configured at the time this task is added. For example, perhaps the
dependencies { } are later in the build script. And so, the set that
runtimeClasspath.collect { ... } may be empty.
Another potential problem is that none of the task which build the runtime
classpath will be added as dependencies of the ear task. A FileCollection, such
as runtimeClasspath, carries dependency information with it, whereas a Set of
files, such as runtimeClasspath.collect { } returns, does not.
You might use something like this instead:
from sourceSets.main.runtimeClasspath.filter { it.isFile() }
> In the end i created a task to call the Ant ear task as follows:
>
> task createEar(dependsOn: 'war') << {
> ant.ear(earfile: "$buildDir/libs/dbUpgrade.ear", appxml:
> "application.xml") {
> fileset(dir: "$buildDir/libs", includes: "*.war")
>
> fileset(dir: "$rootDir/../common/lib" , includes: "log4j.jar
> ProgressOE10openedge.jar ProgressOE10pool.jar")
> fileset(dir: "$rootDir/../uwm/lib" , includes: "isorelax.jar
> msv.jar dom4j-full.jar oisServerUtils.jar oisServerExtensions.jar")
>
> ant.manifest() {
> attribute(name: "Organisation", value: "XXX Information
> Systems Ltd.")
> }
>
> }
> }
>
> assemble.dependsOn createEar
>
> This works, but I have a few questions:
>
> - was there something wrong with the zip task? Why weren't my jars getting
> included?
> - will the prioduction of ear files become a standard task like war? If not
> can you please put some examples of creating with a zip task in the
> documentation
It will eventually, yes. There's a JIRA issue for it, if you want to vote for
it: http://jira.codehaus.org/browse/GRADLE-37
> - I want to limit the jars included to a subset of jars in the classpath but
> couldn't figure out the syntax, is there a way to do this? I ended up using
> filesets with with references to build/libs directories or other projects.
There's a few potential ways you could do this, depending how you want to
decide which jars are in and which are out.
For example, you could write some code to exclude files in the filter { }
closure above, based on the name of the file.
Or, you could add a custom configuration and add dependencies to it. For
example:
configurations {
actualRuntimeJars
runtime.extendsFrom actualRuntimeJars
}
dependencies {
actualRuntimeJars 'some:dep:1.2'
}
task ear(type: Zip) {
...
from configurations.actualRuntimeJars
}
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
