[Geoserver-devel] Moving to gt-property-ng - Final migration

GeoServer GeoServer Developer
1

After the latest batch of geotools changes, both geotools and geoserver will now work with gt-property-ng instead of gt-property (Barring a single test failure in AggregatingDataStore, for which a fix can be found here: https://github.com/geotools/geotools/pull/675).

In order to complete this change, we will be eliminating AbstractDataStore and gt-property.

In addition to PropertyDataStore, the Type Hiearchy of AbstractDataStore contains a number of other classes:
AbstractFileDataStore (gt-main)
ArrayDataStore (gt-main)

CollectionDataStore (gt-main)

MemoryDataStore (gt-main)
PropertyDataStore (docs & gt-property)
VPFFileStore (unsupported/gt-vpf)
VPFLibrary (unsupported/gt-vpf)
WFS_1_0_0_DataStore (unsupported/gt-wfs)

Some of these classes (MemoryDataStore in particular) are used by geotools core classes. If we want to eliminate AbstractDataStore these dependancies will have to be resolved.

Jody has suggested moving the contents of gt-property-ng to gt-property, so than downstream users will not have to update their dependancies.

After this change has been made, a few test cases in geoserver will need to be updated (More will need to be updated if we leave gt-property-ng where it is).
These are all fairly trivial changes, and include adding a method to one of the mocks, changing an instanceof test, and fixing a spelling issue. If gt-property-ng remains where it is, several other name-based tests will need to be updated, and a number of dependancies will need to be updated to use gt-property-ng.

Torben

2

On Thu, Jan 8, 2015 at 7:53 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

After the latest batch of geotools changes, both geotools and geoserver
will now work with gt-property-ng instead of gt-property (Barring a single
test failure in AggregatingDataStore, for which a fix can be found here:
https://github.com/geotools/geotools/pull/675).

In order to complete this change, we will be eliminating AbstractDataStore
and gt-property.

In addition to PropertyDataStore, the Type Hiearchy of AbstractDataStore
contains a number of other classes:
  AbstractFileDataStore (gt-main)
  ArrayDataStore (gt-main)
  CollectionDataStore (gt-main)
  MemoryDataStore (gt-main)
  PropertyDataStore (docs & gt-property)
  VPFFileStore (unsupported/gt-vpf)
  VPFLibrary (unsupported/gt-vpf)
  WFS_1_0_0_DataStore (unsupported/gt-wfs)

Some of these classes (MemoryDataStore in particular) are used by geotools
core classes. If we want to eliminate AbstractDataStore these dependancies
will have to be resolved.

MemoryDataStore is actually used quite a bit, don't think we can just pull
it away. It will have to be migrated to content data store I assume?

Also, don't think we can eliminate a public base class like
AbstractDataStore without a deprecation cycle,
and the class is currently not deprecated.
To give a bit of courtesy to users (and really, just apply our usual
"important public class" phase out methodology),
AbstractDataStore should be deprecated and moved to gt-legacy, and removed
only in geotools 14

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

3

Agreed, AbstractDataStore has a large number of supporting classes that can join it in deprecation.

···

On Thu, Jan 8, 2015 at 11:01 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

On Thu, Jan 8, 2015 at 7:53 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

After the latest batch of geotools changes, both geotools and geoserver will now work with gt-property-ng instead of gt-property (Barring a single test failure in AggregatingDataStore, for which a fix can be found here: https://github.com/geotools/geotools/pull/675).

In order to complete this change, we will be eliminating AbstractDataStore and gt-property.

In addition to PropertyDataStore, the Type Hiearchy of AbstractDataStore contains a number of other classes:
AbstractFileDataStore (gt-main)
ArrayDataStore (gt-main)

CollectionDataStore (gt-main)

MemoryDataStore (gt-main)
PropertyDataStore (docs & gt-property)
VPFFileStore (unsupported/gt-vpf)
VPFLibrary (unsupported/gt-vpf)
WFS_1_0_0_DataStore (unsupported/gt-wfs)

Some of these classes (MemoryDataStore in particular) are used by geotools core classes. If we want to eliminate AbstractDataStore these dependancies will have to be resolved.

MemoryDataStore is actually used quite a bit, don’t think we can just pull it away. It will have to be migrated to content data store I assume?

Also, don’t think we can eliminate a public base class like AbstractDataStore without a deprecation cycle,
and the class is currently not deprecated.
To give a bit of courtesy to users (and really, just apply our usual “important public class” phase out methodology),
AbstractDataStore should be deprecated and moved to gt-legacy, and removed only in geotools 14

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

–
Jody Garnett
Technical Lead | Boundless
jgarnett@anonymised.com
877-673-6436
@jodygarnett

4

Are we all in agreement to replace gt-property with gt-property-ng? Does anyone have any concerns?

Should the old gt-property implementation be completely eliminated, or moved to an unsupported module?

Torben

···

On Thu, Jan 8, 2015 at 11:46 AM, Jody Garnett <jgarnett@anonymised.com> wrote:

Agreed, AbstractDataStore has a large number of supporting classes that can join it in deprecation.

On Thu, Jan 8, 2015 at 11:01 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

–

–
Jody Garnett
Technical Lead | Boundless
jgarnett@anonymised.com
877-673-6436
@jodygarnett

On Thu, Jan 8, 2015 at 7:53 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

After the latest batch of geotools changes, both geotools and geoserver will now work with gt-property-ng instead of gt-property (Barring a single test failure in AggregatingDataStore, for which a fix can be found here: https://github.com/geotools/geotools/pull/675).

In order to complete this change, we will be eliminating AbstractDataStore and gt-property.

In addition to PropertyDataStore, the Type Hiearchy of AbstractDataStore contains a number of other classes:
AbstractFileDataStore (gt-main)
ArrayDataStore (gt-main)

CollectionDataStore (gt-main)

MemoryDataStore (gt-main)
PropertyDataStore (docs & gt-property)
VPFFileStore (unsupported/gt-vpf)
VPFLibrary (unsupported/gt-vpf)
WFS_1_0_0_DataStore (unsupported/gt-wfs)

Some of these classes (MemoryDataStore in particular) are used by geotools core classes. If we want to eliminate AbstractDataStore these dependancies will have to be resolved.

MemoryDataStore is actually used quite a bit, don’t think we can just pull it away. It will have to be migrated to content data store I assume?

Also, don’t think we can eliminate a public base class like AbstractDataStore without a deprecation cycle,
and the class is currently not deprecated.
To give a bit of courtesy to users (and really, just apply our usual “important public class” phase out methodology),
AbstractDataStore should be deprecated and moved to gt-legacy, and removed only in geotools 14

Cheers
Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

5

On Thu, Jan 8, 2015 at 9:13 PM, Torben Barsballe <
tbarsballe@anonymised.com> wrote:

Are we all in agreement to replace gt-property with gt-property-ng? Does
anyone have any concerns?

If everything works in geotools and geoserver, I'd say we have a pretty
good test coverage and as
a result, no concerns.
Just keep an eye on the GeoServer WFS cite tests, the recent changes to
content data store might affect them

Should the old gt-property implementation be completely eliminated, or
moved to an unsupported module?

When I did the same for the shapefile module, I kept a shepefile-old in
unsupported for one release cycle,
just to be on the safe side, maybe someone out there is using it in a
different way, and some bugs might
still be around.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

6

The geoserver test fixes to support the migration are here: https://github.com/geoserver/geoserver/pull/877

Torben

···

On Thu, Jan 8, 2015 at 12:30 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Jan 8, 2015 at 9:13 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Are we all in agreement to replace gt-property with gt-property-ng? Does anyone have any concerns?

If everything works in geotools and geoserver, I’d say we have a pretty good test coverage and as
a result, no concerns.
Just keep an eye on the GeoServer WFS cite tests, the recent changes to content data store might affect them

Should the old gt-property implementation be completely eliminated, or moved to an unsupported module?

When I did the same for the shapefile module, I kept a shepefile-old in unsupported for one release cycle,
just to be on the safe side, maybe someone out there is using it in a different way, and some bugs might
still be around.

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.

7

The pull request for the migration is here: https://github.com/geotools/geotools/pull/679

···

On Fri, Jan 9, 2015 at 3:25 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

The geoserver test fixes to support the migration are here: https://github.com/geoserver/geoserver/pull/877

Torben

On Thu, Jan 8, 2015 at 12:30 PM, Andrea Aime <andrea.aime@anonymised.com8…> wrote:

On Thu, Jan 8, 2015 at 9:13 PM, Torben Barsballe <tbarsballe@anonymised.com> wrote:

Are we all in agreement to replace gt-property with gt-property-ng? Does anyone have any concerns?

If everything works in geotools and geoserver, I’d say we have a pretty good test coverage and as
a result, no concerns.
Just keep an eye on the GeoServer WFS cite tests, the recent changes to content data store might affect them

Should the old gt-property implementation be completely eliminated, or moved to an unsupported module?

When I did the same for the shapefile module, I kept a shepefile-old in unsupported for one release cycle,
just to be on the safe side, maybe someone out there is using it in a different way, and some bugs might
still be around.

Cheers

Andrea

–

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.