On 02/07/2011, at 1:19 AM, Merlyn Albery-Speyer <[email protected]> wrote:
> Hi all, > > 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. Not a lot of work has been done on improving the experience for plugin developers and consumers, and the problem of distribution is something we are acutely aware of. It is something that will be addressed. > This is the kind of DSL change I'm considering: > > apply plugin: 'pluginname', githubid: 'githubid', version: '1.0' > > The key here being that as a side-effect of the apply that it adds an > IvyResolver that will resolve to a URL pattern like this: > "http://cloud.github.com/downloads/[organisation]/[module]/[module]-[revision].[ext]"; > But only for an exact match on the dependency: organisation "githubid", > module "pluginname", and version "1.0". The other side effect of course being > an implicit: "buildscript { dependencies { classpath > 'githubid:pluginname:1.0' } }". Making a hard link on what to apply and where to get it from is a little rigid. What might be better for the short term is to add a new githubDownload() repository notation. Because this needs to be added in the buildscript block, it's going to have to be in Gradle core. Given that github is a popular plugin deployment location I think this is a good interim step. Eventually, there will be a central implicit source for plugins (and a way to define other implicit sources) that will make some if this pain go away.
