Page Operations
Browse SpaceOverview
Move GeoServer trunk to geotools trunk
Proposed By
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:
Email discussion:
Other wiki discussions:
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.