You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2015/01/07 19:08:04 UTC
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
Re: Before branch merges - shapefile class names?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 12/01/15 20:34, Marc Le Bihan a écrit :
> Ok, this is done !
> :-)
Thanks a lot! I will proceed to the merge now...
Martin
Re: Before branch merges - shapefile class names?
Posted by Marc Le Bihan <ml...@gmail.com>.
ok, done.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Monday, January 12, 2015 9:39 PM
To: dev@sis.apache.org
Subject: Re: Before branch merges - shapefile class names?
I just noticed, the Apache license header is also missing in the
following test files...
* AbstractTestBaseForInternalJDBC
* WhereClauseTest
Martin
Re: Before branch merges - shapefile class names?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
I just noticed, the Apache license header is also missing in the
following test files...
* AbstractTestBaseForInternalJDBC
* WhereClauseTest
Martin
Re: Before branch merges - shapefile class names?
Posted by Marc Le Bihan <ml...@gmail.com>.
Ok, this is done !
:-)
Marc.
-----Message d'origine-----
From: Martin Desruisseaux
Sent: Monday, January 12, 2015 1:38 PM
To: dev@sis.apache.org
Subject: Re: Before branch merges - shapefile class names?
Thanks, I applied the changes. This commit contains only EOL or trailing
spaces changes - it does not contains any code or formatting change.
I noticed that the following classes are missing the Apache header
license. Would you have an opportunity to copy-and-paste it? I can do
it, but it may be better if legal stuff like that is recorded in SVN
history as done by the contributor... If you prefer that I had the
license header myself let me know.
* AbstractDatabaseMetaData
* SQLIllegalColumnIndexException
* DBFRecordBasedResultSet
* CrudeSQLParser
About moving the classes in the proposed packages, I can let you do that
when you will have the time if you wish. I should be okay for the merges
now.
Martin
Le 12/01/15 10:55, Marc LE BIHAN a écrit :
> Hello,
>
> Sorry I a bit back of the Apache SIS project for two weeks.
> Please do the changes needed, I can't do them quickly during the next
> days.
>
> Marc.
Re: Before branch merges - shapefile class names?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Thanks, I applied the changes. This commit contains only EOL or trailing
spaces changes - it does not contains any code or formatting change.
I noticed that the following classes are missing the Apache header
license. Would you have an opportunity to copy-and-paste it? I can do
it, but it may be better if legal stuff like that is recorded in SVN
history as done by the contributor... If you prefer that I had the
license header myself let me know.
* AbstractDatabaseMetaData
* SQLIllegalColumnIndexException
* DBFRecordBasedResultSet
* CrudeSQLParser
About moving the classes in the proposed packages, I can let you do that
when you will have the time if you wish. I should be okay for the merges
now.
Martin
Le 12/01/15 10:55, Marc LE BIHAN a écrit :
> Hello,
>
> Sorry I a bit back of the Apache SIS project for two weeks.
> Please do the changes needed, I can't do them quickly during the next days.
>
> Marc.
Re: Before branch merges - shapefile class names?
Posted by Marc LE BIHAN <ml...@gmail.com>.
Hello,
Sorry I a bit back of the Apache SIS project for two weeks.
Please do the changes needed, I can't do them quickly during the next days.
Marc.
2015-01-12 10:39 GMT+01:00 Martin Desruisseaux <
martin.desruisseaux@geomatys.fr>:
> Hello Marc
>
> Sorry to bother you again, but can I process with the "svn:eol-style"
> property?
>
> The reason is that I would like to merge the branches. But if we do not
> fix "svn:eol-style" before and if the files are not identical on all
> branches, then the next merge may report lot of spurious conflicts
> because Subversion may think that every lines have changed (if the EOL
> style is not the same between different branches, for example because
> they have been edited by developers on different platforms).
>
> Also just in case you have the opportunity (but this is only a plus), if
> you have the opportunity to move the files before the merge, that would
> reduce the risk. But this is okay if you prefer not.
>
> Martin
>
>
> Le 09/01/15 09:51, Martin Desruisseaux a écrit :
> > 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
>
>
Re: Before branch merges - shapefile class names?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Marc
Sorry to bother you again, but can I process with the "svn:eol-style"
property?
The reason is that I would like to merge the branches. But if we do not
fix "svn:eol-style" before and if the files are not identical on all
branches, then the next merge may report lot of spurious conflicts
because Subversion may think that every lines have changed (if the EOL
style is not the same between different branches, for example because
they have been edited by developers on different platforms).
Also just in case you have the opportunity (but this is only a plus), if
you have the opportunity to move the files before the merge, that would
reduce the risk. But this is okay if you prefer not.
Martin
Le 09/01/15 09:51, Martin Desruisseaux a écrit :
> 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
Re: Before branch merges - shapefile class names?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
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.
Re: Before branch merges - shapefile class names?
Posted by Marc Le Bihan <ml...@gmail.com>.
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