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?

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'
> 
> 

-- 
Jason Voegele
Keep out of the sunlight.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to