Skip to content
Jody Garnett edited this page Jul 12, 2017 · 1 revision

GSIP 6 - Track GeoTools Trunk

Overview

Move GeoServer trunk to geotools trunk

Proposed By

Jody Garnett

Proposal Type

Policy Change

Assigned to release

GeoServer 1.6

State

Voting, even with acceptance no work will commence until GeoTools policy is changed as described below.

Links

JIRA task:

http://jira.codehaus.org/browse/GEOS-824

Email discussion:

Other wiki discussions:

  • [Observations and Measurements]

GTSteering.pdf

Voting History

Support:

  • +1 Andrea (geotools change management policy has been accepted)
  • +1 Jody
  • +1 RobA
  • +1 Gabriel

Community Support:

  • +1 justin
  • +0 cholmes

Motivations

GeoServer development is driving the majority of changes in the GeoTools library (ie trunk), and GeoServer does not maintain a build tracking GeoTools trunk leaving us open to surprises when it comes time to update; it also leaves GeoTools trunk unstable with respect to our needs.

Assumptions

We can be involved and control the GeoTools development cycle; the stratagy hinges on GeoTools being made available in a timely fashion.

The following assurances have been requested from the geoserver team with respect to this assumption:

  • GeoTools PMC should provide a more formal process for API changes ~~- Action: Andrea and Jesse proposed the change to procedure, issues was accepted as http://jira.codehaus.org/browse/GEOT-1078 and passed. ~~ Nightly Builds that actually run online tests — Work currently underway

Proposal

We should make a build tracking GeoTools trunk - for clarity this should be GeoServer trunk.

Implementation

Update the maven2 dependencies on GeoServer trunk to point towards 2.4-SNAPSHOT.

Backwards compatibility issues

Risks

GeoTools 2.4 is unstable; currently this is due to activity on the OWS4 geoserver branch and work needed for the future of our WCS support. Since these RnD efforts are both GeoServer based the developers involved are already in communication with the project.

A more serious risk is that GeoTools is not suitable for our future needs (see link above); we will need to take part in the planning process and ensure our requirements are met in a timely fashion.

There is a risk that other applications (such as uDig will drive changes adverse to the geoserver roadmap). Channels of communication must remain open.

Participants

Justin Deoliveira Jody Garnett Simone Giannecchini

Clone this wiki locally