+1 for the three repos and history cleanup. I don't think brooklyn-api is useful on it's own, it's tightly coupled to core. Better to stay in the same repo, at least for the time being.
Svet. > On 17.11.2015 г., at 21:08, Hadrian Zbarcea <[email protected]> wrote: > > I think the main motivation for a split would be different release cycles. > For instance it makes sense to have the UI evolve separately and the core and > the ui can have their own release cycles (as long as the API remains the > same). > > It's not clear cut, but I see the REST api staying the the core > (brooklyn-core could be a less confusing name than just brooklyn). > > My $0.02, > Hadrian > > > On 11/17/2015 01:56 PM, Aled Sage wrote: >> +1 >> >> We could also break apart software/webapp/ into separate modules, to >> version separately tomcat, JBoss AS, etc. >> Would those be just different directories with the repo >> "brooklyn-library" presumably? >> >> I think we leave brooklyn-api where it is (i.e. inside /apache/brooklyn). >> >> Does the REST api go in apache/brooklyn or apache/brooklyn-ui? >> >> Aled >> >> >> On 17/11/2015 18:04, Sam Corbett wrote: >>> Big +1 to breaking the version link between everything in software/ (but >>> base/) and the main repository. It is silly that many entities (I'm >>> thinking of you, TomcatServer) are broken out-of-the-box as soon as the >>> maintainers of the software have the temerity to release a new version. >>> >>> The UI is a good candidate to separate too. >>> >>> I have no opinion on brooklyn-api. Have we reached a stable enough point >>> for it to be considered very rarely changing? >>> >>> On 17 November 2015 at 17:44, Alex Heneveld >>> <[email protected] >>>> wrote: >>>> +1 to removing the large artifacts; it's just stupid having them there. >>>> >>>> Personally I would like to see the apache/incubator-brooklyn carved >>>> up as >>>> follows: >>>> >>>> * apache/brooklyn >>>> * apache/brooklyn-ui >>>> * apache/brooklyn-library >>>> >>>> The third one contains all the concrete items, like jboss and tomcat and >>>> cassandra etc. The UI is the jsgui. >>>> >>>> The first one is the main one, with everything else, including CLI and >>>> REST API, vanilla software process, and jclouds locations and osgi. >>>> >>>> >>>> The only other thing I'm wondering is whether brooklyn-api should be >>>> separate, and very rarely changing. This would allow us potentially >>>> to run >>>> different versions of brooklyn-* in the same system, using the magic of >>>> OSGi. >>>> >>>> >>>> WDYT? >>>> >>>> Best >>>> Alex >>>> >>>> >>>> >>>> On 17/11/2015 17:03, Richard Downer wrote: >>>> >>>>> Hi Hadrian, >>>>> >>>>> I don't think there's any need to split the repository (although I've >>>>> no strong opinions on this, if someone else has an idea). >>>>> >>>>> However there has been a long-standing issue with our repository's >>>>> history - in the dim and distant past, binary artifacts of Tomcat etc. >>>>> used for testing were committed to the repository. These are long >>>>> gone, but they still exist in the git history, and everybody is forced >>>>> to clone these large artifacts. >>>>> >>>>> Could we use the graduation migration as an opportunity to rewrite the >>>>> git history to permanently remove these large artifacts? It'd result >>>>> in a much quicker clone of the repo for new contributors to Brooklyn. >>>>> >>>>> Richard. >>>>> >>>>> >>>>> On 17 November 2015 at 00:58, Hadrian Zbarcea <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello Brooklyners, >>>>>> >>>>>> The Brooklyn graduation resolution is again on the board agenda. This >>>>>> time I >>>>>> paid paranoid attention to details and I hope the stars to be better >>>>>> aligned. >>>>>> >>>>>> Assuming all goes well, there will be a few tasks to take care post >>>>>> graduation, mostly related to dropping the "incubating" suffix. >>>>>> Part of >>>>>> that >>>>>> process it is possible to split the git repository into multiple >>>>>> smaller >>>>>> ones. It is possible to do it later, but doing it now would be >>>>>> easier and >>>>>> more natural, I think. >>>>>> >>>>>> Therefore, if anybody has any idea or proposal related to that, >>>>>> speak up >>>>>> now. In the absence of consensus the status quo will be maintained. I >>>>>> will >>>>>> work with infra and try to make the process as smooth as possible >>>>>> for the >>>>>> community regardless of which way we decide to go. >>>>>> >>>>>> Cheers, >>>>>> Hadrian >>>>>> >>
