I'd wait until we have a some better strategy around distributing plugins or writing custom tasks without inheritance.
Cheers! On Wed, Feb 22, 2012 at 6:24 PM, Luke Daley <[email protected]>wrote: > > On 22/02/2012, at 3:52 PM, Szczepan Faber wrote: > > > 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? > > > > Can we detect the problem and throw a meangful exception with > instruction how to resolve the problem? > > The only way we could do this is to watch for it in our class loaders > (i.e. decorate ClassLoader.loadClass()) , and match certain > VerifyError.getMessage() values. I'm not sure we could do that well, but > maybe we could. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Szczepan Faber Principal engineer@gradleware Lead@mockito
