Hi
I was playing around with trying to use the xslt task from Paul Speed
recently discussed on the user list. I made a couple of changes to try
and get it to compile for me, including changing the class def to:
class Xslt extends SourceTask implements Task {
This turned out to be not needed, kind of dumb, and unrelated to the
problem I was seeing (actually just caused by a typo), but in the
process I managed to generate this error:
:buildSrc:compileGroovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
/export/home/crotwell/dev/seis/buildSrc/src/main/groovy/XSLT.groovy:
-1: The return type of
org.gradle.api.internal.tasks.TaskDependencyInternal
getTaskDependencies() in org.gradle.api.internal.AbstractTask is
incompatible with org.gradle.api.tasks.TaskDependency
getTaskDependencies() in org.gradle.api.Task
. At [-1:-1] @ line -1, column -1.
1 error
So it seems that SourceTask and Task are incompatible, which I have to
say is a little surprising given the naming and them both being in the
same package.
The inheritance seems a bit odd to me as well as it seems to bounce
back and forth between the public and internal packages. Perhaps
ConventionTask should be moved to the public api package?
api.task.SourceTask -> api.internal.ConventionTask ->
api.DefaultTask -> api.internal.AbstractTask ->
api.internal.TaskInternal -> api.Task
I suspect this error is just a java oddity where the return type of a
subclass can be more restrictive, but then adding the "implements
Task" further down conflicts, but perhaps this is a reason to not have
the more restrictive return type of TaskDependencyInternal on
AbstractTask, or have the TaskDependencyInternal method use a
different name like getTaskDependenciesInternal()? I presume the idea
is that api.internal should be largely out of sight, out of mind for
task writers.
thanks
Philip
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
