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/TTTTuI > On 9 Sep 2016, at 11:25, Geoff Macartney <geoff.macart...@cloudsoftcorp.com> > 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 <http://is.gd/TTTTuI> > > >> On 9 Sep 2016, at 11:18, Svetoslav Neykov >> <svetoslav.ney...@cloudsoftcorp.com >> <mailto: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 >>> <mailto:andrea.tu...@cloudsoftcorp.com>> wrote: >>> >>> Robert, >>> >>> thanks for your feedback! >>> >>> Alex, >>> >>> https://github.com/apache/brooklyn-client/pull/25 >>> <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 <mailto: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 <mailto: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 >>>>>> <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 >>>>>> >>>> >> >
