hi geoff, andrea-
brooklyn-library is a place to keep a library of blueprints that are
officially part of Apache Brooklyn, not for just any library of code --
see [1]. definitely feels wrong to put it there.
even if you have a preference separate projects, the other question to
ask is whether it is worth the extra pain. i'd factor in a few days
chewed up with apache creating the new repo, updating instructions, and
having every brooklyn dev updating their sub-modules.
also geoff if we extend your argument of mixing code language within a
project we could end up with lots--
brooklyn-client-cli
brooklyn-client-binding-java
brooklyn-client-binding-python
brooklyn-client-binding-malbolge
which i don't like (though i could be convinced).
i have sympathy for the idea that the CLI is different enough from
language bindings that it deserves a separate project. otoh i'm more
inclined to the view that the cli is just the bash language binding. i
also wouldn't expect people to contribute to these projects on their
own, as they mostly track capabilities in brooklyn-server, so the idea
of isolating by language in order to attract developers doesn't feel
very compelling. (the UI in contrast could also be viewed as a client
but it's big enough i can see people wanting to contribute to it.)
i agree with andrea that changing the project name is not worth it,
meaning the options are:
brooklyn-client/
brooklyn-client-bindings/
or
brooklyn-client/
cli/
bindings/java/
as noted earlier, the second option is more straightforward to effect --
in fact basically already done by andrea in [2] modulo one folder change
-- and will have minor impact on brooklyn developers.
note also that whatever we do the docs at [1] should be updated with
this change, and 0.10.0-SNAPSHOT docs published (currently there are none).
--a
[1] https://brooklyn.apache.org/v/0.9.0/dev/code/structure.html
[2] https://github.com/apache/brooklyn-client/pull/25
On 09/09/2016 11:25, Geoff Macartney wrote:
Why not move it to brooklyn-library? It is a library, after all - a REST
client library. Plus, just moving it to brooklyn-client (or anywhere) isn’t
going to do anything to solve the problems Svet mentions in cases where it does
need to be loaded.
As a Go developer I’d be put off contributing to brooklyn-client by Java in it,
and conversely as a Java developer I’d be put off by the Go.
I’m not saying you *can’t* mix the technologies, but suggesting that we
*shouldn’t*.
————————————————————
Gnu PGP key - http://is.gd/TTTTuI
On 9 Sep 2016, at 11:18, Svetoslav Neykov <svetoslav.ney...@cloudsoftcorp.com>
wrote:
Adding some details to the discussion. "brooklyn-rest-client" is not bundled
with the Brooklyn distribution (neither classic nor Karaf). It only shares a repo with
it. resteasy is not causing problems but only because we are not using the client in a
normal Brooklyn distribution.
There are use cases where it needs to be loaded though and that's a headache.
Long term should be fixed to rely on a generic jax-rs implementation and let
the user choose which one fits him best.
It makes sense to have it in the client repo so +1 for that but no strong
feelings here. Slight preference to cli,java top folders.
-1 for a separate repo - too much of them already.
Svet.
On 9.09.2016 г., at 13:14, Andrea Turli <andrea.tu...@cloudsoftcorp.com> wrote:
Robert,
thanks for your feedback!
Alex,
https://github.com/apache/brooklyn-client/pull/25 implements
```
brooklyn-client/
cli/
**/*.go
java/
src/main/java/**/*.java
```
Happy to change it to whatever you guys prefer (Alex's option 2 or option 3)
Personally, I like
```
brooklyn-client-cli/
**/*.go
brooklyn-client-bindings/
java/
src/main/java/**/*.java
```
although renaming `brooklyn-client` to `brooklyn-client-cli` could be
distracting.
Andrea
On 9 September 2016 at 11:54, Alex Heneveld
<alex.henev...@cloudsoftcorp.com> wrote:
i lean towards this:
brooklyn-client/
cli/
**/*.go
java/
src/main/java/**/*.java
or
brooklyn-client/
cli/
**/*.go
bindings/
java/
src/main/java/**/*.java
but I could live with this:
brooklyn-client-cli/
**/*.go
brooklyn-client-bindings/
java/
src/main/java/**/*.java
reason for preferring a single client project is to keep the top-level list
of brooklyn sub-projects tighter (server and client has a nice symmetry ...
and given how much larger server is than all the clients, it'd be odd and
distracting to have multiple client projects)
--a
On 09/09/2016 10:17, Robert Moss wrote:
+1, prefer separate repo, though.
Robert
On 9 September 2016 at 10:03, Andrea Turli
<andrea.tu...@cloudsoftcorp.com>
wrote:
Hi,
I'd like to move `rest/rest-client` out of `brooklyn-server`
brooklyn-server has a dependency on resteasy which is used only by the
rest/rest-client module. Having resteasy and cxf (two jax-rs
implementations) in the classpath looks redundant to me.
Also the extra work needed to support osgi bundles for both. Notice
also jaxrs implementation are not really osgi friendly (ask
@googlielmo and @neykov for more details :P)
So I think a diet for brooklyn-server is not a bad thing :)
Said that, we are discussing with @geomacy
(https://github.com/apache/brooklyn-client/pull/25) if
`brooklyn-client` is the right new place for moving the rest java
client.
We'd like to have more devs involved in this discussion, is it better
moving the java client to `brooklyn-client` (option1) or create a new
project (option2), say `brooklyn-java-client` or
`brooklyn-rest-clients` maybe? Else (option3)?
Thanks,
Andrea
