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
