It was, in fact, language bindings I was talking about. The go client has both language bindings and a CLI in one project. The Java client I was referring to was the rest client not the server CLI, which is just bindings. What I was alluding to was that it might be good to have several language bindings in separate repos and a distinction made between client and CLI.
On 26 November 2015 at 10:51, Alex Heneveld <[email protected] > wrote: > > // moving from VOTE to DISCUSS thread > > *Re what will happen to the existing java client:* > > The Java CLI is for running the *server*. It will live in server > > > *Re 'brooklyn-client' or 'brooklyn-client-cli' (or ***'brooklyn-go-client' > or 'brooklyn-cli' which I don't like):** > > The important thing to differentiate in the repo name (ie the top level I > think) is whether something is for the server, for the CLI client, for the > UI, etc. Language isn't important so I don't like `go-client` -- although > it's nice that the top-level usage/role/repo distinctions do align with > language distinctions! > > Where the language *is* relevant in the name if we're making language > bindings e.g. to facility client code using the REST API. We have this > currently for Java and only in the "rest-client" project. This could be > renamed "rest-client-java-bindings". (On a side note it is proposed that > this go into brooklyn-server for now; semantically this is wrong as it > isn't server code ... but to do otherwise would result in a lot of > cross-project PR's. I don't think it's worth tidying this now; maybe if we > have lots of language bindings then maybe it would be -- e.g. a > `brooklyn-client-rest-bindings` top-level repo.) > > It would be more descriptive for the CLI repo to have > `brooklyn-client-cli` and I'm not opposed to that but it seems long-winded > for a project name. When I hear "client" as a devops context my default is > a client command-line tool; if it's any other type of client -- eg a UI or > language binding -- it would typically be named differently. As in > `brooklyn-ui` and `brooklyn-client-rest-bindings`. > > > *Code-gen:* > > I really like Swagger codegen for creating language bindings / client stub > libraries. With the recent Swagger upgrade I think we do now generate > compliant JSON, exposed through the REST API, and so I think it would be a > simple matter to auto-generate binding stubs for most languages. I've not > tried this with Brooklyn but if someone does, and wants to add a page to > the docs that would be fantastic. (And maybe in future we auto-gen > `brooklyn-rest-client-bindings` for many languages; but not a high > priority.) > > Best > Alex > > > On 26/11/2015 10:05, Andrea Turli wrote: > >> I agree with Robert, that's why I still `+1` `brooklyn-cli` over >> `brooklyn-client` >> >> I'm tempted to suggest `brooklyn-go-client`. What happens to the existing >> >>> Java client, which is not a CLI? Does it deserve its own repo too? What >>> about future language clients? >>> >>> If the brooklyn rest API will be fully Swagger compliant I think a good >> documentation on how how to generate clients in different languages >> starting from the same YAML spec using swagger-codegen will be enough, I >> think. This will offer a good integration with other ecosystems and it >> will >> not require brooklyn community to support all the languages available out >> there. >> >> Cheers, >> Andrea >> >> >
