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:
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 Module Maintainers - you can volunteer as Module Maintainer if you interested.
|x||Visibility||Communicate module status to users|
|x||Intellectual Property Check||Build user trust, OSGeo policy|
|x||Follow the Developers Guide||Project policies|
|x||User Documentation||Ensure work is accessible to users|
|x||Ask||Ask to be included in the next release|
The GeoTools Gold Star Quality Assurance Check defines a couple of quick QA tests allowing you to rate your module according to the number of gold stars it has earned.
The first step is to rate your module:
GeoTools 2.5 and onward expects four stars for a supported module.
Create a README.md file:
The goal here is to make your module status visible to end users.
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.
The file must be named and located as ‘REVIEW.md’
The file should follow the standard layout of the file in the unsupported/example module.
This file describes any contents which do not follow the copyright and license of the project as a whole.
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.
If your module includes code from third-party sources, include a NOTICE.txt file listing these sources and the associated licenses.
The developers guide lists a number of coding conventions, we would like to ensure you line up with the following for a consistent project.
Coding Style: This is easy to check, load up the code formatting in eclipse and hit auto format.
Do not return null.
A simple search for “return null” will often find a few things to think about.
A few searches for “System.out.println” will often find content that needs to be logged.
This one is harder to test, particularly with gobbling exceptions. Searching for “catch (Throwable” often leads to results.
Converting URLs to Files
Use of Assertions, IllegalArgumentException and NPE
Running “FindBugs” will often catch inconsistent names.
Module Directory Structure
Careful attention to use of “OnlineTest” for anything involving the internet. Running a build without your machine to the internet is an easy way to identify online tests.
Maven indicates how long each test takes to run, use of “StressTest” can allow you to cut down on testing time as needed.
The one most likely to cause grief is the JUnit testing requirement.
How to measure test coverage:
Test coverage measured with cobertura or clover.
Run the following for your plugin:
mvn clean cobertura:cobertura
The result is available for each module:
How to use a conformance test: