Thanks Marc.

I would like to fix the "svn:eol-style" and "svn:mime-type" properties
on the Shapefile Java files. Is there a moment when I can do this
operation without disturbing your work?

The operation may appear as if every lines were modified, but it will
actually be Subversion automatically replacing the Windows End Of Line
(EOL) characters by the platform-dependent ones. This is managed
automatically by Subversion for each developer's machine, provided that
we enabled the "svn:eol-style" property. Trailing spaces may also
opportunistically be removed, but no other changes will be applied.

    Martin



Le 09/01/15 07:14, Marc Le Bihan a écrit :
> 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.

Reply via email to