[GRADLE-1677] Apply a plugin and add it's classpath dependency directly via a single Project.apply statement Created: 16/Jul/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: New Feature
Reporter: Merlyn Albery-Speyer Assignee: Unassigned
Resolution: Won't Fix Votes: 1



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.


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 {

{ classpath 'mygroup:myplugin:1.0' }


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.

Comment by Merlyn Albery-Speyer [ 16/Jul/11 ]

I'm working on a candidate solution for this.

Comment by Merlyn Albery-Speyer [ 16/Jul/11 ]

Relates to http://issues.gradle.org/browse/GRADLE-1653 somewhat.
See the discussion thread here: http://gradle.1045684.n5.nabble.com/easy-plugin-integration-td4542479.html

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:01:38 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.