Hello,
I have finished the first part of refactoring.
Done :
- Rename AbstractAutoChecker as AutoChecker.
- Rename AbstractUnimplementedFeaturesOfDatabaseMetaData as
AbstractDatabaseMetaData.
- Rename AbstractBuiltInMemoryResultSet as BuiltInMemoryResultSet (even if
the class is abstract).
- Rename AbstractClauseResolver as ClauseResolver (even if the class is
abstract).
Changed :
- Merge AbstractUnimplementedFeaturesOfResultSet into AbstractResultSet
=> Rename AbstractResultSet to DBFResultSet
and AbstractUnimplementedFeaturesOfResultSet to AbstractResultSet
I have to keep the bunch of unimplemented functions of ResultSet interface
in another class that the base one that is used by all the DBase 3, else
code will be unreadable.
- move AutoChecker to the "org.apache.sis.shapefile.internal.jdbc" package
=>
moved to "org.apache.sis.internal" instead
it's more convenient for me.
Not done :
- 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.
This refactoring part will be done later, I would like to correct the
"String" value problem of the features first, and the refactoring with
DataStoreException.
Regards,
Marc.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Wednesday, January 07, 2015 7:08 PM
To: Apache SIS
Subject: Before branch merges - shapefile class names?
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
