Andrea Aime wrote: > Justin Deoliveira ha scritto: >> I have been working through some jdbc-ng issues lately in an effort >> move it to supported. There are currently two critical bugs outstanding: >> >> http://jira.codehaus.org/browse/GEOT-2488 >> >> Has a patch, but it needs work. > > Oh, if my understanding of that is correct, the report is totally > off the mark, but I did not get feedback from the reporter. > What I think it's going on is that the reporter is using a Postgis > 1.4 beta where the devs have changed the behaviour of envelope > computation and how it always returns 3d envelopes breaking up > the env computation code. The estimated evenlope on the other hand > is forced to be 2d, but that's the wrong solution to the problem > as it's just estimated. > > So I will demote the priority to major. > >> http://jira.codehaus.org/browse/GEOT-2231 >> >> This one has a patch awaiting review from Andrea and Christian. As does: >> >> http://jira.codehaus.org/browse/GEOT-1981 >> >> The rest of patches I submitted seem to have some issues on some >> databases so need a bit of work. >> >> Regardless, i don't seen anything blocking to move it to supported, as >> the modules are working quite well at this point. So I would like to >> start the wheels in motion to move it to supported. >> >> The requirements have all been met, I can write up the necessary pages >> on the wiki, add the modules to the module matrix, etc... >> >> My question is where to put the individual bits. Here is what I had in >> mind: >> >> * Move the contents of unsupported/jdbc-ng/jdbc-core into library/jdbc >> >> There should be no conflicts since the package structures are >> different. That is if we want to keep the old classes in there, >> perhaps we should move them to unsupported? > > 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. > >> * Move the plugins from unsupported/jdbc-ng/* to plugin/jdbc/* >> * Move the old jdbc plugins to unsupported >> >> So the end result would look like: >> >> library/ >> jdbc/ >> >> unsupported/ >> jdbc/ ** if we move the old contents of library/jdbc >> db2/ >> postgis/ >> >> >> plugin/ >> jdbc/ >> db2/ >> h2/ >> postgis/ >> ... >> >> I will write this all up in a formal proposal but just wanted to get >> some conversation going first. > > This works for me. > Cheers > Andrea >
-- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
