[Geoserver-devel] GeoServer and GeoTools versions

(for the geotools folks, a few people were asking about doing Geotools
work and using it in Geoserver. That why I brought the topic up at the
IRC meeting.)

I've been talking to some of the other Geotools folks about whats going
on with 2.1.x and trunk (2.2). Some of it was in the last IRC meeting:

http://docs.codehaus.org/pages/viewpage.action?pageId=31081

Geoserver trunk is currently based on the geotools 2.1.x branch.

Geotools trunk (2.2) is currently being actively developed on, and
there's probably quite a bit of instability and API changes. I dont
know if either of these issues are major or minor.

I've been told there's 5 people going to merge major changes onto
geotools trunk, so I'm hoping to avoid the problems until "someone
else" has tested it out for a bit.

Unfortunately, there's not supposed to be any work going on the 2.1.x
branch, so you're kinda in a catch 22! If you want to do anything of
consequence you have to move to Geotools trunk, which means you'll have
to deal with keeping Geoserver up-and-running with all the (API)
changes they're making there, plus some instability.

Geoserver will switch over to the Geotools 2.2 branch, but probably not
until gabriel finishes his FeatureType stuff. I'd like to see that
stuff in Geoserver & I'm sure he'll have it tested well.

I dont expect moving Geoserver to Geotools 2.2 trunk would take more
than a day or so (the CITE tests should pick up any potential
problems).

Or should I start my own GeoServer branch, port it to GT 2.2.x and go

on

working on it until some point in the future when it may be merged into

GeoServer 1.4.x or

something like that???

The problem is that we're going to probably be making a bunch of changes
to geoserver to do the actual 1.3.0 release, so we'll have to maintain
both geoserver-1.3-for-geotools-2.1.x and the
geoserver-1.3-for-geotools-2.2.

dave

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

dblasby@anonymised.com a écrit :

Geotools trunk (2.2) is currently being actively developed on, and
there's probably quite a bit of instability and API changes. I dont
know if either of these issues are major or minor.

I can't speak for all Geotools modules, but the following apply to module/referencing and the GridCoverage part of module/main:

- Everything that were in 2.1 (excepted @deprecated classes and methods)
   still there in 2.2. If a class or a method presents in 2.1 appears to
   be obsolete or moved to a new location, the old class or method is
   @deprecated, not removed (it will be removed in 2.3 however).

- All new features introduced in the trunk have a @since 2.2 javadoc
   tag. Those features may changes without notice until the 2.2 release
   is out.

Concequently, developpers who want to avoid instability should avoid to use any features with a @since 2.2 javadoc tag until the 2.2 release it out. But other classes or methods (with @since 2.1 or @since 2.0 javadoc tag) can be used without problem (except if @deprecated). If a method with @since 2.1 javadoc tag is broken in the trunk, then it is a regression that need to be fixed. I will fix such regressions in module/referencing and GridCoverage with a high priority.

  Martin.