On Sat, 2010-03-13 at 07:50 +0000, Peter Ledbrook wrote: [ . . . ] > It's not pretty, but it works. It may even be worth considering adding > something to Gradle core for this, or at least a plugin.
I would have thought we should start a community of contributed plugins.
For Python systems such as Bazaar or SCons, then using a DVCS (Bazaar,
Mercurial, or even Git :-) people can have directories (which are Python
packages) that can be pulled and so installed and kept up to date
trivially. As long as there is a search mechanism to find interesting
contributed plugins there is no need to have them necessarily in the
product core -- though they can easily migrate there (or indeed from
there back to the contributed community).
For Java/Groovy systems, jars are the unit of "plugin in" -- whilst
Groovy admits a source as plugin usage, Java does not, so runtime
probably has to be jar. This means either:
1. Publicly uploadable jar repository with pointers to source and
technique of building.
2. Publicly downloadable source with trivial (Gradle-based of course)
build.
In both cases as long as the Gradle core has a place that is
automatically looked up in the classpath for contributed jars, there is
no need to hassle with the start-up classpath. All that is really need
centrally is an index that people can add to (and subtract from).
NB Mechanism 2 is far better for Debian and Ubuntu inclusion since it
means less work for the Debian packagers. Not sure what is best for
MacPorts.
--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: [email protected]
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:[email protected]
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
signature.asc
Description: This is a digitally signed message part
