On Sat, Feb 13, 2021 at 9:28 AM Marc Le Bihan <mlebiha...@gmail.com> wrote:
> Hello, > About workspaces.yaml : I added the corrected yaml file and a test for > [GEOS-9886] workspaces.yaml doesn't carry correct descriptions of REST > services it presents. (as an effect, a working Swagger client cannot be > generated for it) <https://osgeo-org.atlassian.net/browse/GEOS-9886> > > Before creating a pull request to send the corrected > *geoserver/doc/en/api/1.0.0/workspaces.yaml*, > I would like to find a way to put the test I did in geoserver. But it > could a long work, because I don't know how to reproduce all the steps of > my own test project in a manner compatible to geoserver project rules. > And I would like to check the next point to see if it can offer a better > solution too. > I see you are mentioning a Spring Boot test in the ticket, however, GeoServer does not use nor depends on Spring boot. But maybe it could be a separate maven module that only runs tests? That one could be using whatever you like. On the other end, using only technologies/libraries already in use in the project would help in maintenance, modules that long term maintainers are not familiar with, risk of being kicked to the side and eventually removed. Then again, it just takes a single developer to maintain a module, if you're going to be the one, then the above is not a problem. > About openapi.json generation from existing REST services When adding > this dependency to an application (I've used it's version 1.5.3, compatible > with Spring-boot 2.4.1) > > <dependency> > <groupId>org.springdoc</groupId> > <artifactId>springdoc-openapi-ui</artifactId> > </dependency> > > Swagger/OpenAPI immediately makes available > > http://localhost:8080/swagger-ui.html > that produces the same web interface than the one on Geoserver > documentation website. > > http://localhost:8080/v3/api-docs > that describes the REST services in a json format (instead of a > yaml one, but I don't know if it matters). > > This path can be changed with this property : > springdoc.api-docs.path=/geoserver/rest/v3/api-docs > Would it work without having Spring-boot in the classpath? I'll also note the ogc-api modules are already publishing an API endpoint that renders with Swagger, without that particular maven dependency, e.g.: https://tb16.geo-solutions.it/geoserver/ogc/dggs/api?f=text%2Fhtml The setup for the OGC APIs is different, because the yamls have to be adapted on the fly based on the collections in the server, which involves reading a yaml starting template, adapting it with Java code, and re-encoding it back in json/yaml/html. The swagger-ui is referenced directly from the classpath: https://github.com/geoserver/geoserver/tree/master/src/community/ogcapi/ogcapi-core/src/main/resources/swagger-ui and published using a ClasspathPublisher: https://github.com/geoserver/geoserver/blob/master/src/community/ogcapi/ogcapi-core/src/main/resources/applicationContext.xml#L24 If all you need is static files, then a single classpath publisher will do the trick, without requiring any new dependency. Just a matter of placing the files in src/main/resources and add a declaration in the application context. What worries me however is that we're talking just about the workspace yaml file. Is that the only file you're going to add? Having a directly reachable API declaration will just reinforce the idea that the API declarations are machine processable, so it would be best if it did not contain anything that's not working for generating clients, no? 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.*
_______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
