On 16/07/2011, at 3:31 AM, Merlyn Albery-Speyer wrote:
> 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?
I don't think this is going to catch the cases where the apply statement is not
a top-level statement. For example:
subprojects {
apply ...
}
if (project.hasProperty('someProp') {
apply ...
}
init()
def init() {
apply ....
}
I think there are really 2 options to solving this:
1. Limit the places where this type of apply statement can appear in the
script, eg it must be a top-level statement.
2. Don't even try to support changing the build script classpath.
I'd go with option 2. The apply method would work something like this:
1. create a new configuration containing the plugin dependency, and resolve the
configuration.
2. create a URLClassLoader from the resulting files. The parent ClassLoader
should be GradleInternal.getScriptClassLoader().
3. use the ClassLoader to look up the plugin.
Nice and simple. It might be good to have a cache of classloaders created in
step 2, so we can share the implementation classes across all projects in a
build (and, when using the daemon, across builds).
What is interesting about this approach is that plugins are isolated from each
other. The big downside is that the plugin cannot contribute classes to the
build script. But I think it might be a good thing to move away from needing to
do this.
>
> 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
>
>
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
