On Fri, Apr 23, 2010 at 2:01 PM, Jason Voegele <[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 The plugin portal (see below) will provide snippets you just need to copy and paste into your build script. > Is anything like this in the works? Is there anything I can do to help > make such a plugin repository a reality? > We plan to provide the following: 1.) In the apply block you will be able to declare the repositories and metadata where to retrieve a specific plugin from. By default this will be a location like plugins.gradle.org. This approach has a couple of important advantages: -- As we know now the dependency metadata for this specific plugin, we can isolate its transitive dependencies in the plugin classloader to avoid version conflicts. -- It is easier to understand where stuff is coming from and for what purpose if you multiple repos. -- We will use artifactory as the binary repository. It allows to provide additional metadata when deploying to it. This metadata can also be used for retrieving artifacts. In our case that would be the plugin id. -- Using the buildscript section will still be a valid approach. Everything remains backward compatible. You just don't have the convenience and classloader isolation with that approach. 2.) We plan to provide a plugin portal. See: http://markmail.org/message/ss4qa5bycw4naxno Matthias is working on 2.). I'm pretty sure he wouldn't mind some help on that. We can do a lot of good stuff there. Any help would be greatly appreciated. Regarding help on 1.). With artifactory the server side functionality is already there. The other stuff is enhancing the DSL and doing the classloader isolation. We will tackle that soon. We want to make this part of 0.9. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz > > -- > Jason Voegele > philosophy: > Unintelligible answers to insoluble problems. > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
