On Wed, Apr 7, 2010 at 16:27, Adam Murdoch <[email protected]> wrote:
>
>
> 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
>
This would be absolutely amazing! I'd take this over pure documentation :)
--
Jason Porter
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
