Hello Marc
I would like to start merging branches, which is a step needed before
releases. The current plan is to omit the sis-shapefile module for
Apache SIS 0.5 release (for having time to tune its API), but the merge
operations are still easier if the package and class names are stable
(it is okay to move files - it is just easier if there is not too many
moves after the merge).
So what about the following proposals? They are not definitive - it is
only an attempt to get closer to something which, I think, has good
chances to be stable:
* Create a new "org.apache.sis.internal.jdbc" package in the
sis-shapefile module and move in this package all classes that are
designed to be reusable for any JDBC implementation, not only Shapefile.
o This package would be in the "sis-shapefile" module for now, but
a future SIS version could move it in a more generic module if
desired.
o In the current "org.apache.sis.internal.shapefile.jdbc"
packages, only the Shapefile-specific classes would remain.
o Given that some sub-packages may ends up with only one or few
classes, revisit if some sub-packages should be merged with
their parent package.
* Rename AbstractAutoChecker as AutoChecker and move it to the
"org.apache.sis.internal.jdbc" package for now (pending resolution
of API duplication).
* Rename AbstractUnimplementedFeaturesOfDatabaseMetaData as
AbstractDatabaseMetaData.
* Merge AbstractUnimplementedFeaturesOfResultSet into AbstractResultSet.
* Rename AbstractBuiltInMemoryResultSet as BuiltInMemoryResultSet
(even if the class is abstract).
* Rename AbstractClauseResolver as ClauseResolver (even if the class
is abstract).
Martin
