Hi Jason, On Tue, Apr 27, 2010 at 4:51 PM, Jason Voegele <[email protected]> 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? > as said in my other email. Help on the plugin portal app would be greatly appreciated. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > > 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 > > >
