On 06/09/2011, at 3:35 AM, Jesper Nygårds wrote:
> I am trying to put all the dependencies of my Java project into the
> manifest of the project jar, so that I can specify only the project
> jar as the runtime classpath in our server, and have the others
> included. However, I have run into a problem that I can't understand.
>
> I have the following in a build.gradle using the java plugin:
>
> task assembleManifestClasspath {
> project.myjarclasspath = ""
> configurations.runtime.each { file ->
> project.myjarclasspath += file.name + " "
> }
> }
>
> task copyToLib(type: Copy) {
> from configurations.runtime
> into "$projectDir/libs"
> }
>
> jar {
> manifest {
> attributes("Class-Path": project.myjarclasspath)
> }
> }
The code that you provide in the closure for assembleManifestClasspath runs at
configuration time, ie when the build script is executed. It does not run when
the task is executed. So, as far as Gradle is concerned, the task does nothing
and so reports UP-TO-DATE when the task is executed.
You need to do something like, instead:
task assembleManifestClasspath {
doLast {
jar {
manifest {
attributes("Class-Path", configurations.runtime.collect {
it.name }.join(' ')
}
}
}
}
jar.dependsOn assembleManifestClasspath
>
> The idea is to copy all the jar dependencies into the build/libs
> directory where the project jar ends up, and put all these jars into
> the Class-Path attribute in the project jar Manifest.
>
> My problem is that something about the assembleManifestClasspath task
> makes Gradle think that neither assembleManifestClasspath nor
> copyToLib need to be run, even after a clean.
> If I run "gradle clean build copyToLib", it outputs (among the other
> tasks which are properly run):
> :assembleManifestClasspath UP-TO-DATE
> :copyToLib UP-TO-DATE
>
> This is obviously not true, since the copytoLib should put the
> dependency jar files into the build/libs directory, which has been
> wiped by the clean task. I have figured out that it is something about
> iteration over the configuration.runtime files in the
> assembleManifestClasspath task that confuses Gradle, but I don't know
> what is wrong with it.
>
> I realize I'm probably doing this in a backward way, so I would
> appreciate tips both on why my approach doesn't work, and if I should
> use some other approach altogether to gather the classpath into the
> manifest.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
