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
