Motivation
==========

I'd like to make it easier for third party plugins to be integrated into Gradle builds. Right now plugins either need to insist on an internet connection in order to apply a script, or the contents of that script needs to be inlined. "apply plugin: 'xxx'" is so much cleaner than bulky build script dependencies configurations with funky GitHub Ivy resolvers. Getting plugins added to maven central is enough of an obstacle that no-one does it. So, these are the motivating pain points for me.

Solution
========

Being able to inline the dependency declaration into the apply statement is something we've discussed before. The plan is to have the apply statement handle dependency coordinates. You would be able to do any of the following:

1. apply group: 'mygroup', name: 'myplugin-project', version: '1.0', plugin: 'myplugin'
2. apply group: 'mygroup', plugin: 'myplugin', version: '1.0'
3. apply plugin: 'myplugin'

Option 1. would resolve 'mygroup:myplugin-project:1.0' using buildscript.repositories, then scan the resolved artifacts (but probably not their dependencies) for a plugin with id 'myplugin', which it would then load and apply.

Option 2. would use the plugin id as the dependency project name, and resolve 'mygroup:myplugin:1.0' using buildscript.repositories.

Option 3. would work as it currently does now. That is, it scans the build script classpath for a plugin with id 'myplugin'

What this means is that instead of:

buildscript {
dependencies

}

apply plugin: 'myplugin'

You would do:

apply group: 'mygroup', plugin: 'myplugin', version: '1.0'

...

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.