Hi Justin; I would merge and deprecate the classes from the previous effort. I only ripped thejdbc module out of main in order to isolate the jdbc work for improvement after all. The idea is to have a sold core for the geotools library
Jody On Thu, Apr 9, 2009 at 12:36 AM, Justin Deoliveira <[email protected]> wrote: > 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
