On 28/04/10 1:51 AM, Jason Voegele wrote:
Adam/Hans: it seems that plans are already well underway that would
provide at least something very close to what I was asking for.
In what way can I help to make the plans into a reality?
There's plenty of stuff to do in the code, if you're interested. Option
4 below (plugin dev plugin), might be a good place to start. This gives
us a way to shield plugin developers from any meta-data/packaging
changes we need to make to implement the other stuff.
On Sun, 2010-04-25 at 16:47 +1000, Adam Murdoch wrote:
On 23/04/10 10:01 PM, Jason Voegele 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.
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'd love to make this simpler. Here's a few things I'd like to do:
1. We definitely want a well-known plugin repository. That is, you
should be able to do something like:
repositories {
gradlePlugins()
}
Where this is possibly the default for the build script classpath
configuration.
2. Allow you to reference a plugin using the dependency DSL, something like:
apply group: 'mygroup', name: 'myproject', version: '1.2', plugin: 'myplugin
apply plugin: 'mygroup:myproject:1.2:myplugin'
where group, name and version would default to select the official
plugins of the current Gradle version.
3. Allow you to reference a plugin jar by URL, something like:
apply plugin: 'myplugin', from: 'http://someurl/something.jar'
4. Add a plugin development plugin, to take care of bundling up the
plugin jar, generating whatever meta-data is required, and uploading the
lot up to the Gradle plugin repository.
5. Allow a plugin to make classes available to the build script when
apply is used. Currently, to do this, you need to use the buildscript {
} closure.
Combining all these, you could go from something like:
buildscript {
repositories { ... }
dependencies { classpath 'group:name:version' }
}
apply plugin: my.fully.qualified.Type
task mytask(type: my.fully.qualified.TaskType) { .... }
to something like:
apply plugin: 'group:name:version:plugin'
task mytype(type: my.fully.qualified.TaskType) { ... }
or:
apply plugin: 'plugin', from: 'http://someurl'
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
