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/TTTTuI > On 9 Sep 2016, at 13:21, Alex Heneveld <alex.henev...@cloudsoftcorp.com> > 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/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 >>>>>>> >> >
