Adam Murdoch <mailto:adam.murd...@gradleware.com>
13 February 2014 7:50 am
On 9 Feb 2014, at 1:41 pm, Luke Daley <luke.da...@gradleware.com
<mailto:luke.da...@gradleware.com>> wrote:
On 9 Feb 2014, at 10:32 am, Adam Murdoch <adam.murd...@gradleware.com
<mailto:adam.murd...@gradleware.com>> wrote:
On 7 Feb 2014, at 5:09 pm, Luke Daley <luke.da...@gradleware.com
<mailto: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.
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:luke.da...@gradleware.com>
10 February 2014 7:41 am
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?
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:adam.murd...@gradleware.com>
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:luke.da...@gradleware.com>
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
