That's perfectly fine. So where do you stand on the amended proposal,
keeping in mind that we could create new repos or add content to the
repo at will in the future.
For clarity:
[+1] brooklyn-cli (create repo with this name: a heneveld proposal)
[+1] brooklyn-commons-cli (use this name: mzaccardo proposal)
[+1] brooklyn-client (use this name: aheneveld proposal)
[-1] we do not need a separate repo
The way I plan to close this vote is:
* at least 1 negative (-1) vote cancels the proposal
* simple majority on the name wins (only last vote is counted for those
who voted multiple times, e.g. aheneveld's name change proposal.
(and I just realized I don't know what to do with non PMC votes, I need
to think about this one).
The vote is extended until Sun, 11/29/15, 4pm GMT. Plenty of time to
think and decide.
Hadrian
On 11/26/2015 11:53 AM, 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 <[email protected]> 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 <
[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
