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
