I’m trying to cope with Gradle’s missing support for non-local files, and so far my general approach has been to use custom task types. However, this has the annoying limitation of not being able to use any of the other pre-provided or custom task types such as ExecTask, CopyTask etc. After experimenting with possible solutions, I came across what seemed to be a viable solution that solves both problems: Mixing in custom classes into DefaultTask. However, it turned out this messes up task input deserialization as there must be different class loaders. This seems to be unnecessary to me and I’d like to know whether that’s going to change anytime soon. Being able to mix in stuff into DefaultTask without troubles would open up many nice possibilities for Gradle plugins.
I don’t understand which problem you are trying to solve, but I wouldn’t count on getting Groovy mixins to work with Gradle. Among other things, I think that Gradle’s generic task handling only considers physical task properties, and not those added via Groovy mixins (and other forms of runtime meta-programming).
I’m getting a ClassNotFound exception when running code as in the example, because MixinFileCollection can’t be found by the class loader used by Gradle internally, which is baffling, since my class has already been loaded.
Not being able to use Mixins, one of the primary features of Groovy, is unfortunate because it would enable cleaner code and working around single inheritance limitations of the JVM.
If you are keen on using mixins, you might want to try ‘@Delegate’, which has largely replaced the use of runtime mixins in Groovy. Or, if you explained the bigger problem that you are trying to solve (“missing support for non-local files” etc.), we might be able to suggest alternative solutions.
If I’m not mistaken, @Delegate only works for my classes; I, however, want all derived objects of an existing class (DefaultTask) to be affected, because I can’t change its behavior where I need it. I need all tasks to perform the same checks (upToDateWhen, FileNotFound) that inputs.file(s) / outputs.file(s) gives me, but for something else than local files.
If TaskInputs / TaskOutputs could operate on something else than Java Files and would give me an interface for generic input/output objects instead, all of this would be unnecessary.
Groovy runtime mixins are a dead end. Have a look at the new incremental task API that will be introduced in 1.6. Maybe this will help to solve your problems.