Ok. I think I have a workable plan: Changing BuildScriptClasspathScriptTransformer so that it keeps only apply and buildscript MethodCallExpressions (using Spec.or() most likely). Introducing a new DefaultScript variant that uses apply method calls to add to the buildscript classpath dependencies. This will mean that the buildscript classpath configuration will be in the desired state before DefaultScriptPluginFactory.ScriptPluginImpl calls classLoaderProvider.updateClassPath(). BuildScriptTransformer will then need to invert just the buildscript MethodCallExpressions portion of BuildScriptClasspathScriptTransformer's Spec.
Any objections? On Thu, Jul 14, 2011 at 10:06 PM, Merlyn Albery-Speyer <[email protected]> wrote: > Hmm. There's some AST trickery going on in ClasspathScriptTransformer > that treats buildscript closures differently to the rest of the > script. This means that the buildscript closures are applied first and > the the buildscript classpath configuration is RESOLVED long before it > reaches the natural point in the code to add the dependency > (DefaultObjectConfigurationAction). I could dig into the > ClasspathScriptTransformer to make it aware of apply as well...? It > could perhaps clone the apply method statements, transform them to hit > a different code path, and promote them in the script also. Seems > pretty messy to me. Any suggestions for the cleanest way for me to > proceed here? --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
