Hans Dockter wrote:
Hi Adam,
the introduction of the task dependencies had a surprising side
effect. When I have triggered the release build an exception occured
in the following snippet.
zip(classifier: 'all-jdk14').doFirst {Task task ->
task.configure {
zipFileSet(dir: explodedDistDir, prefix: zipRootFolder) {
exclude 'bin/*'
exclude 'lib/gradle*.jar'
exclude 'lib/logback*.jar'
}
zipFileSet(dir: distsRetroLibsFolder, prefix:
"$zipRootFolder/lib")
dependencies.resolve('retrotranslatorAntTask').each { File
file ->
zipFileSet(dir: file.parentFile, prefix:
"$zipRootFolder/lib") {
include file.name
}
}
dependencies is no now longer interpreted as he dependency manager but
as the task property. The call to resolve fails. We could make the
build work by saying owner.resolve. But as the dependency manager is
such an important entity and accessed by the dependencies name I don't
know if we should use the same names. Do you think the name
dependencies (for dependency manager) is a good choice?
Oops. I didn't think that through.
I think 'dependencies' should refer to the dependency manager, and we
should rename Task.getDependencies(). I wonder if we have this problem
anywhere else?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
