Justin Deoliveira ha scritto:
>> I would say, move the current jdbc to unsupported/jdbc-legacy?
>> Otherwise we end up with two gt-jdbc jars and break up the
>> binary distribution, which is a flat list of jars
>> (the the second going in will overwrite the first).
>> Alternatively, we need some other naming for the new library module
>> (dbms, jdbc2, or just jdbc-core?)
> Sure, moving to jdbc-legacy sounds good to me. Alternatively we could
> just keep the old jdbc code in library/jdbc (deprecating it) and just
> add the new code from unsupported/jdbc-core into it? This will allow us
> to keep binary compatibility, and retain the jdbc artifact name.
Meh... yeah, not an easy choice. jdbc-legacy is cleaner, but we never
deprecated the classes in jdbc.
Using the same name for the new jar might confuse people that setup
their classpath by hand ("what? this jdbc.jar is not the same as it
was?").
Striking a compromise, we can go for a deprecation and then
wipe out all the modules in the next round of cleanups (I guess that
will have to wait for 2.7... or maybe just a few minor versions of
2.6, not sure).
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
