I'd like to do option 2. I'll create a JIRA issue for it.
On Jul 15, 2011 2:50 PM, "Adam Murdoch" <[email protected]> wrote:
>
> 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
>
