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.
>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. Jody Aside: I am also willing to switch uDig over to jdbc-ng; the moment I have events working. On Wed, Apr 8, 2009 at 12:53 AM, Andrea Aime <[email protected]> wrote: > Jody Garnett ha scritto: >> >> Sounds good; can we make them part of the default geotools build as well >> then? > > I find it hard to push them for graduation when they're still not able > to replace 1-1 the old jdbc datastores. What we still miss are: > - events (something only uDig is using afaik) > - efficient implementation of aggregating visitors (replacement for > "select max(x) from t" and family). This we'd need in GeoServer as > well, we have a community module using them that would need to be > pushed up to extension sooner or later (sldService). > >> Andrea I started looking into event support for jdbc-ng last night; >> but am still a few evenings away. > > If it's a matter of days, I'd prefer to wait, if it's a matter > of months, better not replace them to start with. Both cases > it seems sensible to wait imho. > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > ------------------------------------------------------------------------------ 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
