[Geoserver-devel] PSC call for vote: backport title and abstract for layer groups

GeoServer GeoServer Developer
1

Hi,
this is a call for vote in order to backport to the stable branch the “Title and abstract for layer groups”
feature landed on trunk some weeks ago via this pull request:
https://github.com/geoserver/geoserver/pull/52/

This backport fixes these two issues:
http://jira.codehaus.org/browse/GEOS-4142
http://jira.codehaus.org/browse/GEOS-5325

It is a configuration change handled the usual way on the stable branch: the two new attributes
are stored in the metadata map, to avoid breaking eventual people trying 2.2.3 and then
deciding to go back to 2.2.2, whilst the code on trunk checks both fields and metadata map.

Davide also took care of preserving backwards compatibility in terms of WMS capabilities
output, if the title is not explicitly set the code will use the layer name like it did before.

The patch seems clean and well tested to me, +1 on the backport.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

2

The patch looks good to me. The forward and backward migration issues are well-thought-out. However, I am not sure where this change stands with respect to API stability.

The stable branch is meant to have a stable API. Because this change adds extra methods to LayerGroupInfo, if I have a third-party plugin that modifies the catalog and adds a new LayerGroupInfo implementation, it will be broken by this change because the third-party class does not implement the new methods. See the changes required to DecoratingLayerGroupInfo, for example.

What do we consider to be the public API? Adding methods to a public interface will break third-party implementations. But perhaps the catalog is seen is internal to GeoServer?

Kind regards,
Ben.

On 04/12/12 17:04, Andrea Aime wrote:

Hi,
this is a call for vote in order to backport to the stable branch the
"Title and abstract for layer groups"
feature landed on trunk some weeks ago via this pull request:
https://github.com/geoserver/geoserver/pull/52/

This backport fixes these two issues:
http://jira.codehaus.org/browse/GEOS-4142
http://jira.codehaus.org/browse/GEOS-5325

It is a configuration change handled the usual way on the stable branch:
the two new attributes
are stored in the metadata map, to avoid breaking eventual people trying
2.2.3 and then
deciding to go back to 2.2.2, whilst the code on trunk checks both
fields and metadata map.

Davide also took care of preserving backwards compatibility in terms of
WMS capabilities
output, if the title is not explicitly set the code will use the layer
name like it did before.

The patch seems clean and well tested to me, +1 on the backport.

Cheers
Andrea

--

Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

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

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

3

On Tue, Dec 4, 2012 at 10:29 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

The patch looks good to me. The forward and backward migration issues are well-thought-out. However, I am not sure where this change stands with respect to API stability.

The stable branch is meant to have a stable API. Because this change adds extra methods to LayerGroupInfo, if I have a third-party plugin that modifies the catalog and adds a new LayerGroupInfo implementation, it will be broken by this change because the third-party class does not implement the new methods. See the changes required to DecoratingLayerGroupInfo, for example.

What do we consider to be the public API? Adding methods to a public interface will break third-party implementations. But perhaps the catalog is seen is internal to GeoServer?

Right, telling what public API is kind of hard in GeoServer.
Generally speaking I think in terms of extension points that people can implement, plugins.

However I cannot imagine one that “plugs” the catalog right now, it would have to be a downright fork instead of a plugin.
I don’t believe we should care for people keeping their fork of GeoServer here, if anything, we should push for these
forks to emerge and join back.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

4

+1 on the backport.

···

On Tue, Dec 4, 2012 at 3:56 AM, Andrea Aime <andrea.aime@anonymised.com8…> wrote:

On Tue, Dec 4, 2012 at 10:29 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

The patch looks good to me. The forward and backward migration issues are well-thought-out. However, I am not sure where this change stands with respect to API stability.

The stable branch is meant to have a stable API. Because this change adds extra methods to LayerGroupInfo, if I have a third-party plugin that modifies the catalog and adds a new LayerGroupInfo implementation, it will be broken by this change because the third-party class does not implement the new methods. See the changes required to DecoratingLayerGroupInfo, for example.

What do we consider to be the public API? Adding methods to a public interface will break third-party implementations. But perhaps the catalog is seen is internal to GeoServer?

Right, telling what public API is kind of hard in GeoServer.
Generally speaking I think in terms of extension points that people can implement, plugins.

However I cannot imagine one that “plugs” the catalog right now, it would have to be a downright fork instead of a plugin.
I don’t believe we should care for people keeping their fork of GeoServer here, if anything, we should push for these
forks to emerge and join back.

Cheers

Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

5

+1

–
Jody Garnett

On Tuesday, 4 December 2012 at 7:04 PM, Andrea Aime wrote:

Hi,
this is a call for vote in order to backport to the stable branch the “Title and abstract for layer groups”
feature landed on trunk some weeks ago via this pull request:
https://github.com/geoserver/geoserver/pull/52/

This backport fixes these two issues:
http://jira.codehaus.org/browse/GEOS-4142
http://jira.codehaus.org/browse/GEOS-5325

It is a configuration change handled the usual way on the stable branch: the two new attributes
are stored in the metadata map, to avoid breaking eventual people trying 2.2.3 and then
deciding to go back to 2.2.2, whilst the code on trunk checks both fields and metadata map.

Davide also took care of preserving backwards compatibility in terms of WMS capabilities
output, if the title is not explicitly set the code will use the layer name like it did before.

The patch seems clean and well tested to me, +1 on the backport.

Cheers
Andrea

–

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it 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

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

On 04/12/12 18:56, Andrea Aime wrote:

Right, telling what public API is kind of hard in GeoServer.
Generally speaking I think in terms of extension points that people can
implement, plugins.
However I cannot imagine one that "plugs" the catalog right now, it
would have to be a downright fork instead of a plugin.
I don't believe we should care for people keeping their fork of
GeoServer here, if anything, we should push for these
forks to emerge and join back.

OK, then I am +1 on this change.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

7

+1

2012/12/5 Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>

On 04/12/12 18:56, Andrea Aime wrote:

Right, telling what public API is kind of hard in GeoServer.
Generally speaking I think in terms of extension points that people can
implement, plugins.
However I cannot imagine one that “plugs” the catalog right now, it
would have to be a downright fork instead of a plugin.
I don’t believe we should care for people keeping their fork of
GeoServer here, if anything, we should push for these
forks to emerge and join back.

OK, then I am +1 on this change.

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

8

+1

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Alessio Fabiani
@alfa7691
Founder/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 331 6233686

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

On Wed, Dec 5, 2012 at 5:22 PM, Christian Mueller <mcrmcr21@anonymised.com> wrote:

+1

2012/12/5 Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>

On 04/12/12 18:56, Andrea Aime wrote:

Right, telling what public API is kind of hard in GeoServer.
Generally speaking I think in terms of extension points that people can
implement, plugins.
However I cannot imagine one that “plugs” the catalog right now, it
would have to be a downright fork instead of a plugin.
I don’t believe we should care for people keeping their fork of
GeoServer here, if anything, we should push for these
forks to emerge and join back.

OK, then I am +1 on this change.

Kind regards,

–
Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d

Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel