On 9 Feb 2014, at 1:41 pm, Luke Daley <luke.da...@gradleware.com> wrote:
> > On 9 Feb 2014, at 10:32 am, Adam Murdoch <adam.murd...@gradleware.com> wrote: > >> >> 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. > > What about Android? Or are we going to encourage the ADT team to publish to > Bintray? I think it’s already available to link to from there, via jcenter. > >> 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. > > I can't think of any good criteria for the initial set. We don't really know > what people are using. One option would be to throw it out to request, but > cap the number. That may not give us the most useful sample set, but I don't > know how to define “useful sample set”. Let’s try that and see what we get. We don’t need many to start with. Which raises another question, of how do people make their plugin available via the repository, beyond this initial stage? We might do this in a few stages, with possibly something kind of manual to start with. > >> There are already a bunch of plugins in the plugins repo. > > There are? Which repo? https://bintray.com/gradle/gradle-plugins > >> We’ll need to make sure that they all have the right meta-data and work with >> the DSL, or move them out (temporarily). > > I'm not sure we want to get into the QA game for all plugins that are > available via this mechanism. We simply don't have the resources. We could > support a subset that are deemed “endorsed” (which is different to > “official”, which would be produced by Gradleware). There are a few things that might be validated here: 1. That we can resolve a plugin id to some ClassLoader setup - so, validate that the meta-data is there, points to some package that can be resolved to a classpath, the dependencies are visible, and so on. 2. That the plugin can be applied cleanly - eg given "apply plugin: ‘my-id’” then `gradle tasks` doesn’t blow up. 3. That the plugin does something useful. We don’t want to automate #3 at this stage, but the long term goal is to enable this in some way. This doesn’t necessarily mean that we’re hosting anything here - it might just be some meta-data that the gradle-plugin-plugin attaches to the package to vouch for the fact that the plugin’s integration tests were run as part of the release process. Let’s park that for now. It’s possibly the same for #2, as this might just be something that the gradle-plugin-plugin does. On the other hand, it’s not a bad way to implement #1. For #1, I think we want to validate this ourselves as well as whatever happens to be validated at publish-time. Initially it might be some manual test, but I think we can, and should, automate this to some degree, and do this early. It would also be a very interesting thing to throw the nightly build against too. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
