Hi,
One thing I haven’t quite worked out is how to handle the migration to
qualified plugin ids, for non core plugins.
In order for plugins to be resolvable via the central plugin service, they must
have a qualified id. This means that authors will have to publish a new
version. The question is whether we encourage authors to move to exclusively
qualified ids, or if they support both for a time.
All plugins initially available via the central plugin service can be used via
the old (i.e. buildscript {}) and new (i.e. plugins {}) mechanisms. One catch
being that the ID has to be qualified to work via `plugins {}`.
Options:
1. Encourage authors to publish new versions of their plugins with qualified ids
2. Encourage authors to publish new versions of their plugins with an
additional qualified id
For #2, the author would just add another META-INF/gradle-plugins/«qualified
id».properties file to their implementation jar. This effectively means that
the plugin jar contains two plugins, that happen to be implemented by the same
class.
The issue with #1 is that users of the new version will have to change their
apply(plugin: «id») statements to use the new qualified id.
The issue with #2 is that it’s potentially more confusing, and we’d probably
have to prevent double application of the plugin (once via qualified, once via
unqualified).
I’m inclined to go with #1 as I don’t think this will be onerous in practice,
and will make qualified ids more pervasive quicker.
Thoughts?
—
Luke Daley
Gradleware
Join us for Gradle Summit 2014, June 12th and 13th in Santa Clara, CA:
http://www.gradlesummit.com
