brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Moss <>
Subject Re: [DISCUSS] Create repo for new deliverable: CLI <- client project name and language binding discussion
Date Thu, 26 Nov 2015 16:53:35 GMT
My original vote (+1 separate repo named brooklyn-cli) still stands.  I was
raising the question since an amendment to the name was raised, whether we
should take into account that other clients exist i.e the the Java rest
client, and consider the possibility of reflecting this with e.g
brooklyn-go-client and brooklyn-java-client repos, and any other language
bindings in future following the same pattern.  It just so happens that the
brooklyn-go-client would have a CLI inside it.

On 26 November 2015 at 16:36, Hadrian Zbarcea <> wrote:

> Alex moved this to a discuss, which I think is a bit confusing. I would
> prefer to keep the vote open even if it takes longer.
> Robert, since you are the one objecting, do you disagree with:
> a. The fact that we need a separate repo for the go client
> b. Don't like the name
> What we put it in the repo is up to us, we can discuss at length later.
> Infra won't create the repo with the given name unless we ask for it. If
> you object to a), I will cancel the thread, if you object to b) hopefully
> we can reach a quick agreement and keep the vote on track. If it's
> something else, it should not be discussed during the [vote].
> My $0.02,
> Hadrian
> On 11/26/2015 06:09 AM, Robert Moss wrote:
>> 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 <
>>> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message