There is also the question of what to do with the old jdbc module. It is a pain to have clashing module names, like we did for the xml stuff. Do we keep calling jdbc-ng "ng", and have the two modules live side by side. Or do we try to merge the two... do we move the old to unsupported?
Andrea Aime wrote: > Jody Garnett ha scritto: >> Thanks for the rational Andrea: >> >> Let me try again; can we include them in the default build (ie not >> requiring a -Dall flag). I understand that graduation may be a ways >> off; GeoServer is already depending on several "unsupported" modules >> such as directory datastore. > > Yup, I have to try and graduate that module up. > >> From my standpoint I try and ensure everything that is in use by uDig >> or GeoServer is part of the default geotools build - so I can deploy >> it in one go. > > Hmmm.... what about oracle datastore classic? > > As per versioning datastore, I did not graduate it because of lack > of feedback. Yes, many expressions of interest, but nobody really > trying to use it. Plus, it would enjoy a rewrite for a couple other > reasons. > > Anyways, I stand on my position, -1 to graduating it unless > we can kick the jdbc datastores in unsupported (or just plain > remove them) in the process. > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
