brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [HEADS-UP] Brooklyn graduation
Date Tue, 17 Nov 2015 19:08:17 GMT
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,

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

View raw message