Hi Gabriel,
seeing the GeoFence experience, I agree with you, the two code bases will
likely evolve at different speeds
and trying to bind them together on the same release cycle is likely going
to be a lot of overhead for little or no gain.

Cheers
Andrea

On Tue, Mar 21, 2023 at 7:35 PM Gabriel Roldan <
gabriel.rol...@camptocamp.com> wrote:

> Hi Jody,
>
> On Tue, Mar 21, 2023 at 1:06 PM Jody Garnett <jody.garn...@gmail.com>
> wrote:
>
>> Your proposal is straightforward and to the point, some feedback for
>> discussion:
>>
>> - I would title the proposal "GeoServer ACL project" (as the important
>> part is a new project; rather than the repository where it is located).
>>
> Done. Good advice.
>
>
>> - One thing I would like addressed in the proposal is indicating how to
>> keep the project in sync with the geoserver update cycle? I do not wish to
>> be in the situation where an "official" geoserver project is running
>> against an unsupported version of geoserver.
>>
>  I've been thinking deeply about this, follow up below.
>
> - The proposal covers publishing maven artifacts which would be done from
>> build.geoserver.org (as I do not wish to see credentials scattered
>> across systems).
>>
> Sounds good to me.
>
>
>> Suggest that "GeoServer ACL" main branch track GeoServer main branch in
>> order to stay in sync and releasable? Taking the geoserver acl client
>> community module to an extension would also meet this goal.
>>
>
> My concern goes beyond version matching.
> For the plugin, as a community module, and at least until it becomes an
> extension, the chances
> to get a good test coverage from the CI builds are very few.
> Besides compatibility with the server part API, concerns are limited to
> the stability of GeoServer's ResourceAccessManager interface and the Wicket
> libraries.
>
> For the server part, the important thing is the REST API
> version/compatibility with the plugin, may it evolve over time.
>
> Making GeoServer ACL's version follow GeoServer's main branch version
> doesn't make a lot of sense, as we'd either be forced to release new
> versions that have no changes, or be unable to, or forced to do additional
> work, if a new GeoServer ACL version is released and it needs to be
> backported to stable geoserver versions.
>
> If both the plugin and the server stay on the same git repository, it's
> easier to ensure they stay compatible, as the CI build can run the
> necessary integration tests, and avoid situations like GeoFence's plugin
> (not embedded) where integration tests are never run, and I couldn't make
> them pass by setting up a standalone instance as indicated in the tests
> comments.
>
> So, being a separate product, having its own life cycle make the most
> sense, and moreover, the CI builds could run plugin integration tests
> against several geoserver versions for a single GeoServer ACL version. e.g.
> mvn verify -Dgs.version=2.24-SNAPSHOT
> mvn verify -Dgs.version=2.23.0
> mvn verify -Dgs.version=2.22.2
>
> Then the GeoServer plugin's community module itself could be a practically
> empty jar with pure dependencies, on a specific gs-acl version.
>
> To exemplify, gs-acl 1.0 is released, the geoserver community module
> depends on gs-acl-plugin:1.0 for the main branch, and all the stable
> branches.
>
> When gs-acl 1.1 is released, we change the dependency of geoserver's main
> branch community module to gs-acl-plugin:1.1.
>
>  Gabe
>
>>
>> --
>> Jody Garnett
>>
>>
>> On Tue, Mar 21, 2023 at 6:23 AM Gabriel Roldan <
>> gabriel.rol...@camptocamp.com> wrote:
>>
>>> Hi all,
>>>
>>> as discussed in the "GSIP-216 GeoFence 4.0.x" email thread, I've created
>>> a new GSIP to request hosting the GeoFence fork, called GeoServer ACL, as a
>>> sibling project to GeoServer, GeoFence, and GeoServer Cloud, under the
>>> /geoserver Github organization.
>>>
>>> Please see https://github.com/geoserver/geoserver/wiki/GSIP-217 for
>>> details, comment back and vote.
>>>
>>> Best regards,
>>> Gabriel.
>>> *camptocamp*
>>> INNOVATIVE SOLUTIONS
>>> BY OPEN SOURCE EXPERTS
>>>
>>> *Gabriel Roldan*
>>> Geospatial Developer
>>>
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>


-- 

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts!

Visit http://bit.ly/gs-services-us for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions Group
phone: +39 0584 962313

fax:     +39 0584 1660272

mob:   +39  339 8844549

https://www.geosolutionsgroup.com/

http://twitter.com/geosolutions_it

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

Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE
2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si
precisa che ogni circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è
riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il
messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se potesse darmene notizia.

This email is intended only for the person or entity to which it is
addressed and may contain information that is privileged, confidential or
otherwise protected from disclosure. We remind that - as provided by
European Regulation 2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than the intended
recipient is prohibited. If you have received this email by mistake, please
notify us immediately by telephone or e-mail
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to