Niclas has made some very good points here.Any steps towards addressing points 2 and 3 would be leaps of progress compared to other OS toolkits/frameworks out there :-) cheersMagnus
From: nic...@hedhman.org Date: Thu, 13 Feb 2014 12:53:36 +0800 To: dev@gradle.codehaus.org Subject: Re: [gradle-dev] Hardcoded list of plugins for new plugin mechanism. My 2 jiao as a happy Gradle user; The biggest challenge with independent plugins is basically not technical, it is how maintain a high-quality experience with varying quality plugins over long periods of time. 1. "Independent" Plugins tend to be developed by a person when he/she needed it, and from then on never touched, until someone else forks it and make the changes he/she wants after that. GitHub is a catalyst to make this much more common than the "old days", when there was an anti-fork incentive, and things like Apache thrived on the "community model" with a single source repository. For Gradle, this means that an "excellent plugin" today is likely to degrade in quality over time, as it doesn't keep up with Gradle changes/abstractions/conventions. In itself, it is not Gradle's fault, but I think Gradle could help make the experience better for us poor users who will eventually suffer from this. a. Require plugins to have a "Published Date" and have "Warnings" as the plugin is getting "too old", probably both by actual date as well as number of Gradle core releases in between. b. Tie the plugin to a particular Gradle release plus N releases after. So, if the plugin was written for 1.10 and N=6, I can use the plugin in 1.15 but if I try to use it in 1.16, it will be "gone". If then Gradle keeps anything deprecated around for N releases, in theory the plugins shouldn't start breaking. 2. The suggestion that Gradle runs integration tests of plugins, as part of the release process would be really cool. However, I think it will be incredibly challenging. However, a "high quality plugin" should be able to have its own integration tests/server and a way to report back to Gradle of any problems that occurs when testing against nightly Gradle builds. 3. Create a non-Gradleware-operated community for plugins, with zero entry barriers. Let the community self-organize, but provide reasonable infrastructure for it to function. CheersNiclas On Thu, Feb 13, 2014 at 5:50 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote: 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 -- Niclas Hedhman, Software Developer 河南南路555弄15号1901室。 http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/6a2pl4j I relax here; http://tinyurl.com/2cgsug
