-
Notifications
You must be signed in to change notification settings - Fork 1
GSIP 6
Move GeoServer trunk to geotools trunk
Jody Garnett
Policy Change
GeoServer 1.6
Voting, even with acceptance no work will commence until GeoTools policy is changed as described below.
http://jira.codehaus.org/browse/GEOS-824
Email discussion:
Other wiki discussions:
- [Observations and Measurements]
Support:
- +1 Andrea (geotools change management policy has been accepted)
- +1 Jody
- +1 RobA
- +1 Gabriel
Community Support:
- +1 justin
- +0 cholmes
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.
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
We should make a build tracking GeoTools trunk - for clarity this should be GeoServer trunk.
Update the maven2 dependencies on GeoServer trunk to point towards 2.4-SNAPSHOT.
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.
Justin Deoliveira Jody Garnett Simone Giannecchini
©2020 Open Source Geospatial Foundation