On Mon, 2009-07-20 at 09:43 +0200, Hans Dockter wrote: > On Jul 19, 2009, at 10:54 AM, Russel Winder wrote: > > > I started trying to get the Cobertura plugin in some form of fit state > > to at least compile using Gradle HEAD. I seem to be on a loosing > > battle > > as there appears to be no documentation about writing plugins -- > > unless > > I just missed it. Chapter 24 of the user guide is t.b.d. > > The only thing that has changed is the signature of the plugin method. > I have updated the breaking changes page: > > http://docs.codehaus.org/display/GRADLE/Gradle+0.7+Breaking+Changes
This is only true if you know the semantics before and after. The
problem here is the parameters. Simply stating the signature has
changed is true but isn't actually that helpful. The shift from
PluginRegistry and Map to ProjectPluginsContainer is a huge change of
algorithmic requirement and the API documentation is not really in a fit
state for anyone not intimately familiar with the internals of the
Gradle implementation to work out what changes are needed.
OK so for the Gradle developers there is no problem, but for people
trying to write and maintain plugins other than the ones in the Gradle
core, this is likely a real problem and a real turn-off.
I have seen many people begin to blog about Gradle and Gradle plugins,
which is great. However, their material is now wrong and this must be
managed carefully. These people need approaching to write about
updating their plugins material, ensuring it is clear which Gradle
version each article applies to, and *most important* how to transform
old plugins to new ones.
From a personal perspective, I am begining to feel I have no idea how to
evolve the Cobertura plugin I was trying to build up based on the work
of Phil Messenger and Luk Morebee. Perhaps this is my fault, but I
believe it is an indicator that more care and attention over the
evolution and promulgation of explanation of changes is needed to avoid
Gradle becoming a ghetto.
I think Gradle has a great potential future. The evolution is fine
since it makes Gradle better. Once Gradle reaches 1.0 it is going to be
nigh on impossible to change for quite long periods, so it is important
that any necessary revolutionary changes are made in the lead up to 1.0.
However, the community needs to be carried with core developers to avoid
ghettoization.
I don't think there needs to be any revolutionary change here to get
things right, it just requires as much emphasis on the documentation as
there is on the code. We have a skeletal user manual that is a huge
potential asset. Ditto the JavaDoc and GroovyDoc materials. They just
need the same emphasis as the code itself.
Sorry for ranting a bit, but I feel stymied in trying to evolve a plugin
by the changes to Gradle that assume I don't need any support other than
the source code.
--
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
