I'm doing some work on cleaning up or dynamic classes/interfaces. I had a go at deprecating convention task, and removing it from the class hierarchy. I wanted to do this because it leaks a lot of internal classes onto the public API. This works ok, except for Groovy.
If a user has a task written in Groovy that extends from any of our tasks that extend ConventionTask, they would need to recompile their code. If they don't, a java.lang.VerifyError will be thrown when their Groovy task subclass is be loaded. I've asked the groovy folk about this: http://groovy.329449.n5.nabble.com/Changing-class-hierarchies-of-compiled-against-classes-td5505384.html If the task subclass is Java then there's no problem. At the moment I have no solution for the Groovy problem. What do we want to do here? It seems to me we are going to have to do this at some point. For example, ConventionTask exposes IConventionAware and ConventionMapping which are both internal. At some point, ConventionMapping will go public which means moving it… which means binary incompatibility. Removing ConventionTask has another unrelated implication. Tasks will no longer be able to set their own convention mappings in their constructors. With the way things currently are, any mapping setup will be silently ignored (which is a separate issue to fix). Should I make the change (i.e. deprecate ConventionTask and remove it from the class hierarchy) or leave it alone and defer the pain? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
