From: Chris Holmes <cholmes@op...> - 2003-09-30 19:00:02
Apologies for the large cross-post, please direct replies to
The gt2wms server is moving to the GeoServer project. We've been wanting
to move the wms server out of GeoTools for awhile, as it doesn't really
fit with the rest of the modular nature. Over at GeoServer we were
planning on integrating the gt2wms anyways, so it seems to make sense to
have the code actually live on in the same cvs. This way our developers
can benefit from one another's approaches, and hopefully combine common
code. Both are OGC web services on top of Geotools, so there should be a
few places of overlap. I'm planning on spending the rest of this week on
integration, and initial attempts are promising. I've successfully got
them running in the same war, and can recieve a getCapabilities document
There are a few questions that I have, for all interested in the future of
gt2wms, and its integration into geoserver.
1. How much integration do we want? I think common configuration would be
nice to have, so that both services could use the same configuration
files. GetCapabilities responses and Exception handling also seem like
they have some overlap, so we might try to combine those classes. We can
talk more specifics on the geoserver devel list.
2. Maven on GeoServer? The GeoServer project currently uses ant, which is
nice and fast, and currently easier to get working (though maven 1.0 may
prove that wrong). Getting GeoServer on Maven would allow us to more
quickly pick up geotools changes - right now I hand roll the geotools jar
and put it on cvs, which is obviously less than ideal. My plan is to
start tagging geotools with geoserver tags of what is needed, but using
maven would make that less necessary, as it would just download the proper
jars. I'm a bit inclined to stay with ant, but if someone (James?) is
willing to set it up and no one's against the change I'll go along.
3. Package names for the gt2wms. Do we want to keep the geotools package
names, since that's where the code comes from? Or do we want to make a
org.vfny.geoserver.wms package? Or if we're going for a lot of
integration we could make org.vfny.geoserver.requests.wms and
org.vfny.geoserver.responses.wms, and put all the common config code in
org.vfny.geoserver.config. And we can obviously start with one and move
things around if and when we actually acheive integration.
4. Distribution and Marketing. These questions are not pressing, but how
do we want to present the wms? Should we make it available as a
stand-alone wms? Keep the downloadable war format? Integrate it
completely into GeoServer? Create seperate installation instructions?
Many of these questions depend on how much we integrate, but even if we do
integrate a lot we can still have them live as slightly different projects
in user's minds, just ones that inter-operate quite well.
Ok, I'm sure there will be more questions about this, but we can hold off
for discussion on geoserver-devel.