Hi Marc, I'm not sending you a different response, but it's probably not what you wanted.
The three answers I gave you all point towards solving the problem, you just have to be the one making the PRs, as I said, they would be welcomed. If your expectation is that others would stop what they are doing and help you, then indeed, you will not get that. Cheers Andrea On Mon, Feb 8, 2021 at 10:08 AM Marc LE BIHAN <mlebiha...@gmail.com> wrote: > Ok. I stop considering the problem. > > When you write : "Nobody is using the yamls to generate clients right now, > anyways." > I'm exactly. Because now many REST services are described by them and it's > more easy to have client generated by Swagger : it avoids constructing > request and parsing json or xml response to put them in an (or some) > objects manually. > And when I was searching for a solution on GIS Stackexchange, ignoring > where the problem was coming from, you were among who told me to come on > Geoserver project instead of asking, and handle it myself if I wanted a > solution. > > It's what I did, I've spent twenty hours already on it and found one. > > And now, you send me a different response. > > > Le lun. 8 févr. 2021 à 08:48, Andrea Aime <andrea.a...@geo-solutions.it> > a écrit : > >> On Sun, Feb 7, 2021 at 10:00 PM Marc Le Bihan <mlebiha...@gmail.com> >> wrote: >> >>> For that, I think the best thing to do would be to annotate server >>> classes and object to allow Swagger/Open Api to produce their exact >>> declarations of services in a new yaml file. >>> But this new yaml file and Swagger-UI documentation should be in another >>> URL, let say /geoserver/rest/v2/... to ensure that existing code that rely >>> on version 1 of the API can continue to use /geoserver/rest/... without >>> trouble . >>> (but this is only the beginning of a solution...) >>> >> >> I don't see the need of a v2, you're not changing the existing REST API >> implementation and the resource representations no? Just its description. >> Nobody is using the yamls to generate clients right now, anyways. >> >> Also, in general, versioning will likely not work, the API changes little >> by little as new needs pop up, we'd be at "v200" (exaggerating of >> course) if we considered every >> model change happened so far, and every new resource addition or new >> request parameter. >> >> What we typically try to do, is to preserve backwards compatibility, that >> is, a client written for a previous release should keep on working with the >> new one (new fields are optional), new parameters in resource requests >> are optional. >> >> As said in my previous mail, the yamls are just documentation at the >> moment: I don't know why you explain that a client can be generated >> from YAML files if they are correctly set up (we know that very well), as >> I told you already, right now it's not a goal, due to the limited staffing >> of the project. >> The yaml files have been hand written once, and then mostly left there to >> rot. >> >> If you want to join in the effort to make the yaml files maintainable, >> and provide resources for both its initial setup and long term maintenance, >> then we can make >> "yaml as code generation support" a project goal too. Otherwise there is >> nothing to discuss, it's not a matter of "right or wrong", >> it's a matter of having the man hours to do an initial version of it, and >> then look after it in the long term. >> Existing developers are busy up to their eyeballs and more, there is no >> amount of reasoning that will change that. >> >> >> >>> My question is : >>> Do you want this file to be integrated in the restconfig project with a >>> test if I can create one that is convincing, >>> or do you think it's too much, too early, and I better keep these >>> corrected file for myself, for my own use only ? >>> >> >> First step, treat it as documentation and simply issue a fix for the yaml. >> >> Second step, if you can write a test that generates a client, and can use >> it in an interaction with a GeoServer, >> in a fully automated way, that is also welcomed (you might need to >> setup a GitHub action build too, if the >> test needs a live GeoServer to work against, otherwise no one will run >> those tests). >> >> Third, if you want to have reliable yamls that you can generate clients >> for, make a plan for it, write a GSIP >> <https://docs.geoserver.org/stable/en/developer/policies/gsip.html>, >> resource it fully, and then implement it. Do it in a way that the system >> is self sustaining (every deviation >> gets a test failure) and you might not need to be involved long term all >> that much (but plan for some). >> >> >> Regards, Andrea Aime >> >> == 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.* >> > -- Regards, Andrea Aime == 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
