Can we detect the problem and throw a meangful exception with instruction how to resolve the problem?
-- Szczepan Faber Principal engineer@gradleware Lead@mockito 22-02-2012 16:35 użytkownik "Luke Daley" <[email protected]> napisał: > 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 > > >
