On 24/04/10 4:45 PM, Hans Dockter wrote:
On Fri, Apr 23, 2010 at 2:01 PM, Jason Voegele <[email protected]
<mailto:[email protected]>> wrote:
I am the author of the Android plugin for Gradle, and I have added the
Android plugin information to http://gradle.codehaus.org/Plugins
However, it seems to me that it is more difficult than it should
be for
users to use plugins that are not distributed with the Gradle
core. For
example, for someone to use my Android plugin requires all of this
Gradle code:
buildscript {
repositories {
mavenRepo urls: 'http://jvoegele.com/maven2/'
}
dependencies {
classpath 'com.jvoegele.gradle.plugins:android-plugin:0.8'
}
}
apply plugin: com.jvoegele.gradle.plugins.android.AndroidPlugin
Whereas, for any plugin distributed with the Gradle core, it is as
simple as:
apply plugin: 'scala'
I would like to have some sort of well-known plugin repository that
Gradle knows about by default and can search for plugins without
requiring the user to declare the repository in their build.gradle
file.
I fully agree.
Furthermore, I would like for this plugin repository to map simple
names
(e.g. "android") to fully-qualified plugin names (e.g.
"com.jvoegele.gradle.plugins.android.AndroidPlugin").
I think we should switch our id pattern to fully qualified names, like
org.gradle.Java, or com.jvoegele.gradle.Android
Another option is to use (group, moduleName, version, pluginId) as the
fully qualified plugin identifier. Then, there is a natural mapping to
determine the artifacts for the plugin - that is, use (group,
moduleName, version).
A composite id also allows us to infer parts of the id that haven't been
supplied. For example,
apply plugin: 'java'
could simply be shorthand for:
apply group: 'org.gradle', moduleName: 'plugins', version:
gradle.gradleVersion, plugin: 'java'.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
