Thanks, guys, comments inline. On Tue, 23 Mar 2021 at 10:31, Andrea Aime <andrea.a...@geo-solutions.it> wrote:
> On Tue, Mar 23, 2021 at 1:44 PM Gabriel Roldan <gabriel.rol...@gmail.com> > wrote: > >> A convenient choice has been made in configuring the object model mapper >> so that whenever a change is made to the internal model (e.g. CatalogInfo >> class hierarchy), the build will fail on this new module, forcing to keep >> them up to date. >> > > +1, just one note on the above: we will not see the failures, as community > modules are built without running tests (by policy). > Sorry, I mean a compile-time error. But in any case, I was mistaken, because that part is not included in this "client only" contribution, although I might add it later in order to enforce (me) to keep the models up to date. To be clear, IF we have a mapping from the "presentation model" (the pure api dto's) and the internal model (e.g. *Info), a compile-time error can be thrown (if configured to do so) whenever there are missing mappings from properties of one model to the other. Why the two models? because outside of geoserver, there's no notion of CatalogInfo et.al., and the "pure api" model lets you create clients and server stubs in all languages supported by the openapi generator. Nothing prevents you from setting up a separate build server that will run > the tests. > > I'm a bit worried about the double maintenance in the long term, every > time we change a bean in the core GeoServer > configuration, a corresponding change will have to be made in the client > library. As long as it's a community module, > not a problem (or else, your problem, LOL), it will become annoying if > this module ever graduates to extension, as the > maintenance burden will be placed on all other developers as well. > I know that, and IMO, it's an acceptable burden in order to keep them aligned. If you add a property to FeatureTypeInfo, so add it to the model object in catalog.yaml and call it a day. But as mentioned above, not a concern right now. Cheers, Gabe. > > Cheers > Andrea > > == GeoServer Professional Services from the experts! Visit > http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf > Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa > (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 > http://www.geo-solutions.it 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.* > -- Gabriel Roldán
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
