Hi there,
IMHO the feature of supporting any script via URL is a killer feature,
especially combined with github.
I'm sharing another plugin repo at github with Grégory Boissinot, which
was initially created to work on the PDE Plugin for Eclipse RCP apps.
Today I moved a few lines of an older build script to a simple plugin
script to support AspectJ. Support for "inpath" (not needed yet) and a
sample will be added soon. see
"http://github.com/breskeby/gradleplugins/raw/0.9-upgrade/aspectjPlugin/aspectJ.gradle";
for further infos or
"http://github.com/breskeby/gradleplugins/tree/0.9-upgrade";
regards,
René
ps.: Hans, looking forward to meet you at JUGS tomorrow.
Hans Dockter schrieb:
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
--
------------------------------------
Rene Groeschke
[email protected]
http://www.breskeby.com
------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
