Hardcoded list of plugins for new plugin mechanism.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Hardcoded list of plugins for new plugin mechanism.

Luke Daley-2
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.

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Adam Murdoch

On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Luke Daley-2

On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]> wrote:

>
> On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]> 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?

> 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”.

> There are already a bunch of plugins in the plugins repo.

There are? Which 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).

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).

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Adam Murdoch

On 9 Feb 2014, at 1:41 pm, Luke Daley <[hidden email]> wrote:


On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]> wrote:


On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]> 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?




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



Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Niclas Hedhman
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.



Cheers
Niclas


On Thu, Feb 13, 2014 at 5:50 AM, Adam Murdoch <[hidden email]> wrote:

On 9 Feb 2014, at 1:41 pm, Luke Daley <[hidden email]> wrote:


On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]> wrote:


On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]> 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?




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
Reply | Threaded
Open this post in threaded view
|

RE: Hardcoded list of plugins for new plugin mechanism.

Magnus Rundberget-3
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 :-)

cheers
Magnus


From: [hidden email]
Date: Thu, 13 Feb 2014 12:53:36 +0800
To: [hidden email]
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.



Cheers
Niclas


On Thu, Feb 13, 2014 at 5:50 AM, Adam Murdoch <[hidden email]> wrote:

On 9 Feb 2014, at 1:41 pm, Luke Daley <[hidden email]> wrote:


On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]> wrote:


On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]> 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?




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
Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Luke Daley-2
In reply to this post by Adam Murdoch


> Adam Murdoch <mailto:[hidden email]>
> 13 February 2014 7:50 am
>
> On 9 Feb 2014, at 1:41 pm, Luke Daley <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>
>> On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>
>>> On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]
>>> <mailto:[hidden email]>> 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.
So it is. I didn't realise that “packages” that are in JCenter because
they were sync'd from central also show up in Bintray. That solves this
problem.

>>
>>> 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.
I'd say initially we just use the Bintray “link package” GUI. This will
send a message on Bintray to us, and then we approve/deny the request.

There's a story in the spec already for working this stuff out
(https://github.com/gradle/gradle/blob/8799c1b939fc9e0b8e4e73ad120f55746b3455a7/design-docs/publishing-and-sharing-plugins.md#story-plugin-author-requests-that-plugin-version-be-included-in-the-gradle-plugins-repository).
I don't think we need to do any forward planning on this before we get
to that story.

>>
>>> 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.
I agree. It won't be difficult.

Added this to the spec:
https://github.com/gradle/gradle/commit/8799c1b939fc9e0b8e4e73ad120f55746b3455a7

> It would also be a very interesting thing to throw the nightly build
> against too.
Leaving that out of this spec as it's separate.

>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
> Luke Daley <mailto:[hidden email]>
> 10 February 2014 7:41 am
> On 9 Feb 2014, at 10:32 am, Adam Murdoch<[hidden email]>  wrote:
>
>> On 7 Feb 2014, at 5:09 pm, Luke Daley<[hidden email]>  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?
>
>> 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”.
>
>> There are already a bunch of plugins in the plugins repo.
>
> There are? Which 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).
>
> 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).
>
> Adam Murdoch <mailto:[hidden email]>
> 9 February 2014 10:32 am
>
>
>
> 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
>
>
>
> Luke Daley <mailto:[hidden email]>
> 7 February 2014 4:09 pm
> 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.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Hardcoded list of plugins for new plugin mechanism.

Luke Daley-2
In reply to this post by Niclas Hedhman


> Niclas Hedhman <mailto:[hidden email]>
> 13 February 2014 2:53 pm
> 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.
To some extent, but the responsibility for choosing quality software
components if first and foremost with the user. Nothing we can do will
prevent the requirement for users to do due diligence in researching the
software they are going to use. There are no free lunches, and we should
be explicit about 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.
Publish date makes sense. Not sure about the warnings as that's very
subjective.
>   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.
I'm not keen on such artificial constraints. Some plugins may
successfully have a long life and not need changes.
> 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.
I'm not sure about such a high tech solution. Test coverage is
subjective, so pass/fail is pretty meaningless. Ultimately, if a user is
doing due diligence they should be looking at the test suite and what
was tested. I'd rather make the gradle tooling support having good
quality tests for plugins, and publish the test reports as part of the
release process.
>  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.
This is basically what we have now. With regard to the new mechanism,
the plan is to open it up to other channels as well. Initially this will
be arbitrary bintray orgs (most likely), but other possibilities as well
eventually.


Thanks for the input.

>
>
>
> Cheers
> Niclas
>
>
>
>
>
> --
> 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
> Adam Murdoch <mailto:[hidden email]>
> 13 February 2014 7:50 am
>
> On 9 Feb 2014, at 1:41 pm, Luke Daley <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>>
>> On 9 Feb 2014, at 10:32 am, Adam Murdoch <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>>
>>> On 7 Feb 2014, at 5:09 pm, Luke Daley <[hidden email]
>>> <mailto:[hidden email]>> 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
>
>
>
> Luke Daley <mailto:[hidden email]>
> 10 February 2014 7:41 am
> On 9 Feb 2014, at 10:32 am, Adam Murdoch<[hidden email]>  wrote:
>
>> On 7 Feb 2014, at 5:09 pm, Luke Daley<[hidden email]>  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?
>
>> 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”.
>
>> There are already a bunch of plugins in the plugins repo.
>
> There are? Which 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).
>
> 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).
>
> Adam Murdoch <mailto:[hidden email]>
> 9 February 2014 10:32 am
>
>
>
> 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
>
>
>
> Luke Daley <mailto:[hidden email]>
> 7 February 2014 4:09 pm
> 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.
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email