Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Aled Sage]

+1 for single brooklyn-client repo with subfolders 'cli' and 'java'.

Aled


On 09/09/2016 13:41, Geoff Macartney wrote:

hi Alex et al.

I guess those are fair points - it still makes me a bit queasy but I’ll go with 
the majority if they are happy to move it there. Don’t think I voted yet so I 
will say +0.  :-)

I certainly agree that there’s no point in changing the ‘brooklyn-client’ repo 
name.  In terms of repo structure I’d be happy enough with Andrea’s current PR 
(subfolders ‘cli’ and ‘java’ - I think ‘bindings’ is implicitly clear).


Geoff




Gnu PGP key - http://is.gd/uI



On 9 Sep 2016, at 13:21, Alex Heneveld  wrote:


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/uI



On 9 Sep 2016, at 11:18, Svetoslav Neykov  
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  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
 wrote:

i lean towards this:

   brooklyn-client/
   cli/
   **/*.go
   java/
   src/main/java/**/*.java

or

   brooklyn-client/
   cli/
   **/*.go
   bindings/
   java/
   

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Geoff Macartney]

hi Alex et al.

I guess those are fair points - it still makes me a bit queasy but I’ll go with 
the majority if they are happy to move it there. Don’t think I voted yet so I 
will say +0.  :-)

I certainly agree that there’s no point in changing the ‘brooklyn-client’ repo 
name.  In terms of repo structure I’d be happy enough with Andrea’s current PR 
(subfolders ‘cli’ and ‘java’ - I think ‘bindings’ is implicitly clear).


Geoff




Gnu PGP key - http://is.gd/uI


> On 9 Sep 2016, at 13:21, Alex Heneveld  
> wrote:
> 
> 
> 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/uI
>> 
>> 
>>> On 9 Sep 2016, at 11:18, Svetoslav Neykov 
>>>  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  
 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
 

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Alex Heneveld]

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/uI



On 9 Sep 2016, at 11:18, Svetoslav Neykov  
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  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
 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

wrote:


Hi,

I'd like to move `rest/rest-client` out of `brooklyn-server`

brooklyn-server has a 

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Geoff Macartney]

oh - adding my comments from the github discussion for completeness:

geomacy commented 2 hours ago
@andreaturli what's the reason for this? I think it would be better to keep the 
br CLI as a separate, Go, project, and not add in unrelated code. If there's 
some reason why the rest client needs to be moved away from brooklyn-server 
let's move it somewhere independent. 

Despite the project name, brooklyn-client is a consumer of the REST API, not a 
client library, and I don't see that this is the right place for the REST 
client code.


andreaturli commented 2 hours ago
As for the reason: brooklyn-server has a dependency on resteasy which is used 
only by the rest/rest-client module. Having resteasy and cxf (2 jax-rs 
implementations) in the classpath looks redundant, not considering 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 :)


geomacy commented 2 hours ago
It just feels wrong to me from the "keep things decoupled" / "do one thing" 
viewpoint. If I am a Go developer I might want to contribute to the 
brooklyn-client, but if I have no Java background as well I will be put off by 
all that Java. Adding the REST client here mixes together two completely 
different technologies in one project. 

   
geomacy commented 2 hours ago
the resteasy issue is its own thing, we should fix that in brooklyn-server, or, 
if moving the code is the right solution, fair enough, but I don't think this 
is the right place to move it.



Gnu PGP key - http://is.gd/uI


> On 9 Sep 2016, at 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/uI 
> 
> 
>> On 9 Sep 2016, at 11:18, Svetoslav Neykov 
>> > > 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 >> > 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
>>> > 
>>> 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 

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Geoff Macartney]

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/uI


> On 9 Sep 2016, at 11:18, Svetoslav Neykov 
>  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  
>> 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
>>  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
 
 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
> 
>>> 
> 

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Andrea Turli]

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
 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
>> 
>> 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
>>>
>

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Alex Heneveld]

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 
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

Re: [PROPOSAL] Remove rest/rest-client from brooklyn-server

[Robert Moss]

+1, prefer separate repo, though.

Robert

On 9 September 2016 at 10:03, Andrea Turli 
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
>