The GeoTools library plays host to several "unsupported" components, here is the process for formally including your work in the as a core part of the GeoTools library.

Why Support your Module You do get a couple of benefits from having a supported module: your work is bundled up as part of the GeoTools release process You can have a couple of seconds JUnit test time to verify your module works You can create Online-Tests for cruise control to run

Picking up a Module If you are interested in picking up an unsupported module (perhaps it was abandoned?) have a look into the section on 3 Module Maintainers - the GeoTools can set you up as Module Maintainer if you interested.

Visibility / Module Status

The GeoTools Module Matrix defines a couple quick QA tests allowing you to rate your module according to the number of gold stars it has earned.

1. The first step is to rate your module:
   • Gold Star Quality Assurance Check
2. The second step is to ensure you meet the standard set for the release:
   • GeoTools 2.3 - just rate your module
   • GeoTools 2.4 - three stars are required to be included
   • GeoTools 2.5 - four stars are required
3. Create a Module Matrix page:
   • show project status
   • list jira issues (from as many projects as possible)

The goal here is to make your module status visible to end users.

Intellectual Property Check

Your module must have a file presenting the providence review of the contents of your module including the copyright and licenses which apply to your module. This file must describe any contents which do not follow the copyright and license of the project as a whole. Deviations which require later fixes should have a link to a JIRA task explaining the issue and describing the plan to resolve the issue or remove the offending resource.

The file must be named and located as 'src/site/apt/review.apt'. The file must be in the "Almost Plain Text" format and should follow the standard layout of the file in the unsupported/example module.

The goal here is to show that each and every file has been looked at, by hand, and any issues of copyright or licensing have been addressed. Fixing some of these issues in the past has required "stubbing" some of the jar dependencies with dummy code of the same signature from a third party JAR which we cannot distribute.

Follow the Developers Guide

The developers guide lists a number of coding conventions:

• 5.1 Coding Guidelines
• 5.2 Naming Conventions — use PMD
• 5.3 Module Directory Structure
• 5. 5 Refactoring
• 5. 6 Code Profiling
• 5. 7 Testing — JUnit
• 5. 8 Test Data
• 5. 9 Versioning

Test Coverage and Maven Profiles

The one most likely to cause grief is the JUnit testing requirement, please be aware that the tests may be performed by cruise control (especially if they are on-line tests requiring the use of web services).

Initially the GeoTools library aimed for 60% test coverage, for now we will stick with:

• GeoTools 2.3
  • Correct use of Online-Test
• GeoTools 2.4
  • Test Coverage measured and published to Module Matrix page
  • Coverage of 30% measured by a cruise control profile (you can supply a test fixture so the nightly builds can run against your database)
  • Making use of a Conformance test if available

For help setting up your test fixture and maven profile for the nightly build box please contact the geotools-devel list.

Test coverage measured with clover ... run mvn site for your plugin and look at the clover report. As an example the clover report for shapefile is mentioned here: http://maven.geotools.fr/reports/modules/plugin/shapefile/clover/index.html The report indicates that shapefile has 58% test coverage:

Conformance Tests

We are looking into the creation of conformance tests to verify plug-in completeness and correctness.

GeoTools 2.4:

• DataStore conformance based on MemoryDataStore example
  • Verify concurrency and event notification
  • Verify constant time performance of metadata queries

User Documentation

Currently have a very simple requirement for user documentation. Please make something (anything!) available in GeoTools User Guide wiki and link to it from your module matrix page.

It is recommended that you make a single example showing how to use your module or plugin.

• 02 User Guide (Writing Guidelines for the User Guide)

Ask to be included in the next release

Finally you can ask to be included in the next release, show up at a weekly IRC meeting or send an email to the list. (chances are there will be questions)