Skip to end of metadata
Go to start of metadata

Motivation:

Clarity of purpose

Contact:

full name

Tracker:

http://jira.codehaus.org/browse/GEOT-1953

Build Change

http://jira.codehaus.org/browse/GEOT-1955

Developers Guide Change

Tagline:

got code?

The introduction of unsupported modules has been a great success; now that we are nearing the release of GeoTools 2.5.0 we need to sort out a few build issues; and nail down exactly how to make modules supported.

Description

We introduced the "modules/unsupported" directory in an effort to help prevent the development community working on branches; and as an effort to introduce new developers to the GeoTools community. This also allowed us to demote several modules that have been with out a maintainer (so it is obvious to the user community what is going on).

This proposal would like to refine how we are handling unsupported modules:

  • The creation of a single page in the developers guide outlining all the requirements from creation through supporting a module (right now this content is split across several pages). We should clarify how a module can drop back to unsupported status and so forth.
  • Modify the unsupported/pom.xml so that profiles are available grouping like functionality; using a single environmental -Dall to turn on all functions
  • Deployment of all modules to maven (including those in unsupported)
  • Continuous testing of all modules (including those in unsupported)
  • Restrict unsupported modules from the default download

The goals here are several fold:

  • Ensure that everything we (ie the PMC) make available for download has passed the Project QA checks and meets the requirements of our Developers Guide
  • Continue to foster new development
  • Ensure that GeoTools always builds in a reasonable amount of time

Status

We would like to close up this issue in a timely fashion for the 2.5.0 release:

Discussion

Tasks

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success

 

no progress

(tick)

done

(error)

impeded

(warning)

lack mandate/funds/time

(question)

volunteer needed

  1. (tick) API changed based on BEFORE / AFTER patch is waiting to be applied, this is required to make 2.5.0 ready for release
  2. (jive) Update the developers guide and ask for review
  3. Ask a module to step through the process in order to "debug" the procedure

API Changes

BEFORE

Currently all children of unsupported/pom.xml are included in the build (or they are placed into a profile like "archive" if the code does not compile).

AFTER

We need to place the majority of unsupported modules into individual profiles; activated with a common -Dall command line setting:

Documentation Changes

This proposal requires modification to the Developers Guide:

  • No labels