Good point about unsupported/jdbc - we do not want to change the module name. We should leave the implementations that are not ready yet where they are.
Slightly off topic (I saw Andrea mention this on the user emaillist). One of the tasks associated with moving a module to supported is running it though the QA star program; which involves setting up a module matrix page. It appears as though Andrea has managed to produce a maven site on his own - and is just waiting for deployment instructions. Is there any chance we can replace the module matrix page with maven site documentation? Even as just a documentation convention... Jody On Thu, Jul 2, 2009 at 4:13 PM, Justin Deoliveira<jdeol...@opengeo.org> wrote: > Another to probably mention is that we probably don't want to move all > of the modules over just yet. For instance mysql and sqlserver don't use > spatial indexing as of yet, so until they do they probably are not ready > for prime time, so we could just keep them in unsupported for the time > being. Thoughts? > > Justin Deoliveira wrote: >> 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. >> >> 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? >> >> * 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. >> >> -Justin >> > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > ------------------------------------------------------------------------------ > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
