On 7 Feb 2014, at 5:09 pm, Luke Daley <luke.da...@gradleware.com> wrote:
> Hi, > > I'm working on > https://github.com/gradle/gradle/blob/master/design-docs/publishing-and-sharing-plugins.md#story-resolve-hard-coded-set-of-plugins-from-public-bintray-repository. > > To wrap this up we need to decide what the list of plugins will be. The only > one mentioned in the spec is the Android plugin. > > I'm actually not sure we even want to do this (i.e. create a hardcode list of > plugins we know how to resolve) at this point. The Android plugin is the > primary driver here, but it's not going to be that useful. The main > limitation is that plugins loaded with the new mechanism are isolated in > terms of classloaders. This means that if someone uses the new plugins {} > block to bring in the Android plugin then they cannot use any plugins that > collaborate, of which there are quite a few out there now. I think rolling > this out without plugin collaboration working for such an important user > segment will ultimately lead to bad press. > > Given that the next story (i.e. being able to dynamically resolve plugins > from Bintray) is reasonably close to done (i.e. likely to be in 1.12), I > think we should just skip the hardcoded list and reassess if we need it for > the Android case when we support plugin collaboration. The idea of the hard-coded list story was to let us to the DSL first, without bothering too much about resolution. We ended up doing things in the other order, so there’s not really much point to the story any more. A related question, though, is which plugins are we going to include initially in the plugins repo, and how do we decide what’s in and what’s out? The plan - for those who haven’t read the spec - is that we roll this out initially with a pretty small set of plugins that we select by hand, and then gradually roll this out to include every plugin that would like to be included. There are already a bunch of plugins in the plugins repo. We’ll need to make sure that they all have the right meta-data and work with the DSL, or move them out (temporarily). -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
