Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

It's bee a while too, no objections, so yeah (imho, but I don't remember the rules by heart) Cheers Andrea On Mon, Apr 10, 2017 at 6:40 PM, Torben Barsballe < tbarsba...@boundlessgeo.com> wrote: > Now that this has gotten at least 50% +1's, are we good to merge? PR is > here:

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Now that this has gotten at least 50% +1's, are we good to merge? PR is here: https://github.com/geoserver/geoserver/pull/2101 Torben On Tue, Apr 4, 2017 at 10:30 AM, Kevin Smith wrote: > On 2017-03-20 09:09 AM, Torben Barsballe wrote: > > This was initially proposed just

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

+1 from me Ian On 21 March 2017 at 09:50, Andrea Aime wrote: > Thanks for the clarification > +1 then :-) > > Cheers > Andrea > > On Mon, Mar 20, 2017 at 6:31 PM, Torben Barsballe < > tbarsba...@boundlessgeo.com> wrote: > >> I took a look, and none of the changes

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Thanks for the clarification +1 then :-) Cheers Andrea On Mon, Mar 20, 2017 at 6:31 PM, Torben Barsballe < tbarsba...@boundlessgeo.com> wrote: > I took a look, and none of the changes are strictly backwards-compatible > > The changes to CatalogPostModifyEvent are changes to a public interface.

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

+1. Seems necessary, and the changes are not too intrusive. Kind regards, Ben. On 21/03/17 05:09, Torben Barsballe wrote: > This was initially proposed just prior to the 2.11-beta release, but did > not make it in in time. > Re-opening for discussion and voting now that the code freeze has

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

I took a look, and none of the changes are strictly backwards-compatible The changes to CatalogPostModifyEvent are changes to a public interface. The changes to AbstractCatalogFacade are protected, but will affect anything extending AbstractCatalogFacade. Everything else is mostly just

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Hi Torben, it would help, imho, if the proposal separated the API changes that are actual backwards incompatible ones. E.g., adding method to the event class is not an API break at all. Makes easier to argue that the changes are isolated in places that are not really meant to be implemented

[Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

This was initially proposed just prior to the 2.11-beta release, but did not make it in in time. Re-opening for discussion and voting now that the code freeze has ended. Refer to https://github.com/geoserver/geoserver/wiki/GSIP-157 This proposal is to update the CatalogPostModifyEvent (and

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Given the lack of feedback, I think I will defer this until after the code freeze, aiming for the 2.12 release. The CatalogFacade changes are only likely to affect alternative catalog implementations. Given that this is something that probably should have been included in the initial

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Hi Torben, sorry I lost track of this one, too many things going on. I too got bitten by this limitation of the API, and while it breaks an interface, I'm not aware of an easy way to plug a different Catalog implementation, so I guess all current implementation are actually inside the GeoServer

Re: [Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Torben have you gotten any feedback? Is this in for tomorrows release ... I do not see this as a risky change; adding a new event notification does not have any backwards compatibility concerns. -- Jody Garnett On 10 February 2017 at 10:22, Torben Barsballe wrote:

[Geoserver-devel] GSIP-157 - Track change state in CatalogPostModifyEvent

Continuing from earlier discussion, a GSIP is required in order for this change to actually get into GeoServer, see: https://github.com/geoserver/geoserver/wiki/GSIP-157 This proposal is to update the CatalogPostModifyEvent (and associated firePostModifed methods) to track changed values, similar