On 6/04/10 3:46 AM, Jason Porter wrote:
I'm sitting in IRC with Steve Ebersole trying the best I can to answer
questions about plugin development. Having not written one myself,
but having looked at the code for some plugins I have to say that
starting and understanding how to create a new Plugin and make use of
things like upToDate checking, configuration, caching (which I don't
know if there is a cache) is exceptionally cumbersome.
Those of us that would like to write plugins really need a plugin
developer doc that takes us through various use cases from basic
(probably not as basic is "Hello World") to more advanced. Other
things to include would be setting up the classpath to include gradle
/ groovy, including third party jars and packaging it all up to be put
out in a repo,
I wonder if this would be better solved by adding a plugin development
plugin. Then you would only need to:
apply plugin: 'gradle-plugin'
and this might:
* Add gradle and groovy to the compile classpath
* Generate the appropriate meta-info file(s) to include in the jar,
based on, say annotations in the source code or meta-data in the build
file. For example, you might do
@Plugin(id = 'myplugin')
class MyPlugin implements Plugin<Project> { ... }
and the appropriate stuff ends up in the jar so that users of the plugin
can do apply plugin: 'myplugin'
* Generate the appropriate dependency descriptor, whatever that happens
to look like.
* Add the gradle integration test fixtures to the testCompile classpath
and later, it might provide:
* Tasks to generate scaffolding: eg, a task for adding a new plugin or
task, which adds the template source files and integration tests to the
right places
* Some way to bundle build scripts into the plugin jar with an id, so
they can be used in the same way as compiled plugins.
* Tasks to upload the plugin plus meta-data to the central Gradle plugin
repository
* Generate and upload the standard plugin documentation
* Upload the integration tests so that we can, for example, do nightly
integration tests of Gradle snapshots against released plugin, or plugin
snapshots against released Gradle or ...
* Ways to deal with changes between Gradle versions, such as an easy way
to integration test against a bunch of different Gradle versions, or
even some kind of retrotranslate for the Gradle API.
This has the added benefit that I'd much rather implement the above
stuff as code in a gradle plugin plugin, than implement it as a pile of
words in the user guide.
a better explanation of methods and annotations for task and plugin
development, and probably others I'm not thinking of :)
I'll definitely add some stuff about the task annotations before the 0.9
release. I'd like see a few more patterns emerge before documenting too
much other stuff in the user guide - but we should always document stuff
in the javadocs.
As of right now the standard has been hang out in the mailing lists,
google for tutorials that are probably out of date, or read the gradle
code itself. None of these are really great options, especially as
Gradle starts to become more widely adopted. I don't know if it's too
much to ask, but a guide of this sort would be extremely valuable at
the 0.9 release.
These are all good points. I'll try to do some more before then.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
