brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [DISCUSS] Create repo for new deliverable: CLI <- client project name and language binding discussion
Date Thu, 26 Nov 2015 17:08:02 GMT


Thx for explanation.  For me it's about emphasis.  The message of this 
proposal for code-browsers is:

* brooklyn-client is *the* main client you should use; look at it and 
you'll see it's a cli, and it happens to be written in go, but that's 
not relevant at a high level
* there is also a ui, obviously at brooklyn-ui
* there is a rest client binding for java but currently it's buried; 
these might be promoted at some point but they'd never be the main 
client project; I expect they'd be called something like 

I think we sometimes overcomplicate things for people when we try to 
precisely describe everything rather than taking a stand. #toomanyphds

@Hadrian-  I had no intention to close the VOTE; I was simply 
redirecting discussion off the VOTE thread.  +1 to reaching consensus in 
which case I think the process should be Robert replying to the VOTE 
thread indicating so.


On 26/11/2015 16:53, Robert Moss wrote:
> 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,
>>>>> 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

View raw message