Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [udig-devel] Thinking of a 1.0 release checklist 
David Zwiers wrote:


On Tue, 2005-01-25 at 12:17, Jody Garnett wrote:
Here is the wiki page - <http://docs.codehaus.org/display/UDIG/Plugin+1.0+Requirements>
This is a scratch pad of good ideas for battening down the hatches for 1.0 release of a plugin. We are considering these steps now, so we know what to do as we approach the UDIG 1.0 release. 

  1. Assign a plugin maintainer with following responsibilities:
         * Front line contact person
         * Accepts patches for *bug* fixes to plugin

Most cases a test case would be recommended/ required. Test cases are a
great way to get to know the code, make valuable contributions, and
prove that your fix actually fixes stuff :).
I will leave that to the plugin maintainer to figure out. I already have a guideline for tests - "if the plugin maintainer cares there should be a test for it". Do not wish to make it hard for bug fixes to be submited. 


  3. Have a build.xml file for use with nightly builds, include run
     of testcases

This is hard, and may also require some planning depending on how you
wish to manage sub-projects.
Okay that was a bad idea and we will skip it. The plugins can be built like normal. We can use the api rules of engagement naming conventions to allow you to latch onto the test plugins and run those from your nightly build. 


  6. Class and interface javadocs are required, even if only one
     sentence.

For packages which are flaged 'internal' this should be relaxed (package
name includes 'internal'). 
That was assumed by, me - the Programmers Guide has the details.


  7. package javadoc recomended location for code example
For strategic pacakges that are the focus of the framework, such as Catalog, Tools, Renderer, StyleConfigurator, MapGraphics and so on a tutorial will be required as part of the Developers Guide. 
Hope this includes a recipe for making an extension ... ie a quick
example.
That is what a tutorials is :-) The tutorial should cover plugin.xml requiremetns and and using your extention point schema.xml. 
Question: should we make code which will have an obvious failure if it
is copied and pasted?
You can provide method body examples cut & paste examples. Nobody is expecting an entire plugin that can be copied and modify - such a beast exists in the Eclipse workflow and is part of the New Plugin Wizard - you can write a plugin template if you want. I don't have time. 

Jody

Back to the top