On 23/09/2010, at 9:48 AM, Philip Crotwell wrote:
> 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.
They are actually compatible. SourceTask implements Task. What you're seeing is
a Groovy problem. If you were to try the same thing with a Java source file, it
would compile fine.
>
> 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?
It probably should, yes. Or perhaps just merged into DefaultTask.
>
> 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,
It's a Groovy oddity, rather than a Java oddity.
> 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.
Exactly.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
