My 2 cents on the matter... I'd go for separate packages. The OGCAPI modules are right now pure protocol implementation, while the "engine" is really in the classic OWS services. The pure protocol part is the one that is most subject to change, and if they ever do a v2 it will be (by semantic versioning) breaking. If the packages are named "v1" there will be room for a "v1.1" inside, with minor modifications and hopefully no convoluted logic to share code.
On the other end, there is no talk at all about a v2, part because v1s are still in the making, part because the small core + extensions lends itself to adding functionality by simply adding new extensions. But yeah.... while it's not clear to me which way would be the best based on information we have today, all in all a v1 package seems the safer way to go. Cheers Andrea On Mon, Feb 6, 2023 at 10:56 PM Joseph Miller <millerjos...@gmail.com> wrote: > I am looking into the best approach to handling versioning in the new OGC > API endpoints from a code maintainability perspective. > > In WFS an "adapt" call is used to match a request to an embedded subclass > of the request type (see for example > https://github.com/geoserver/geoserver/blob/de184b2f9ed9a844b5291dd163e772132a07689b/src/wfs/src/main/java/org/geoserver/wfs/request/GetFeatureRequest.java#L28 > and > https://github.com/geoserver/geoserver/blob/de184b2f9ed9a844b5291dd163e772132a07689b/src/wfs/src/main/java/org/geoserver/wfs/request/GetFeatureRequest.java#L196 > ) > > Along those lines In the OGC API we could use a Path variable to determine > which subclass or version of the method to call. An example of this > approach can be found here: > > https://github.com/turingtestfail/geoserver/blob/bb764ec698dae9db627af452d3a5e4404fa2d926/src/community/ogcapi/ogcapi-maps/src/main/java/org/geoserver/ogcapi/maps/MapsService.java#L114 > > The downside of this approach would be that if major version changes of > the OGC API represented big differences the parent classes could become > large and unwieldy. > > An alternative to the subclass approach would be to organize things by > package - an example of this approach can be found here: > https://github.com/turingtestfail/geoserver/blob/e69867256e2124677233faad94ef4a095a7f0259/src/community/ogcapi/ogcapi-tiles/src/main/java/org/geoserver/ogcapi/v1/TilesService.java#L80 > > The downside of this approach is that multiple packages could end up with > redundant code and a confusing file structure for maintainers. > > Thanks in advance for any feedback, > Joe Miller > _______________________________________________ > 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
