Hi, Adam has posted recently to the dev list about a fantastic new feature: http://markmail.org/message/6ucpqju7g2yfvx2p
Any script can now be a plugin and can live either locally or remotely. You can use this feature for build script composition for for reusing functionality. For the latter just drop your gradle build script wherever you want it to live. People then just need to specify the URL and Gradle download the script, compiles it and applies it to your build. Their are many scenarios that can make use of this feature. One important scenario for us is that we want to avoid bloatedness of the Gradle API. There are many possibly interesting additions to our API. Yet we might not be sure yet whether it is worth incorporating them or what's the best of implementing them. Now there is an easy possibility for staging such candidates. I have started my own plugin repo at Github (called huglins for Hans' plugins). For example there is a feature request for a convenience method to create fat jars (http://jira.codehaus.org/browse/GRADLE-566). There is now a fatjar.gradle you can use to have such a feature: apply url: 'http://github.com/hansd/huglins/raw/master/fatjar.gradle' jar { merge configurations.runtime } task otherJar { merge files(fileTree('lib').matching { include '**/.jar' }) } It is very easy to maintain those script plugins. When they live in Github (launchpad, bitbucket) you can also easily version them. We believe that to lower the threshold/overhead for sharing code is a key for a fertile active plugin system in the Gradle community. Things are just more fun/agile etc... that way. They are also a great knowledge base. One other thing we want to tackle is that the Gradle cookbook makes use of it where it make sense. Those plugins are complimentary to plugins that are shipped within a jar. The latter are more complex, often have their own additional domain classes, etc.... In this context I would also like to point out the plugin collection of Robert Fischer: http://github.com/RobertFischer/gradle-plugins They don't use the new mechanisms yet, thus can be used from Gradle 0.8. As a side note. There is a lot of goodness in the 0.9 branch. The trunk is already in use for building Gradle itself as well as building Grails and a couple of other projects. The documentation is not fully updated yet but besides that we can definitely recommend to use it. All of the above only works with trunk. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
