brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <>
Subject Re: [DISCUSS] new repos and project migration
Date Thu, 26 Nov 2015 11:12:48 GMT
Sorry, I missed the [DISCUSS] thread and posted on the [VOTE] thread.

But to repeat:

> * brooklyn - all files in the root (no subdirs)

The files in the root are:


All of these except pom.xml would also be present in every *other*
repository, with minor modifications. This repo is not pulling its

> * brooklyn-dist
>     usage/all
>     usage/dist
>     usage/scripts
>     usage/downstream-parent
>     usage/archetypes

My recommendation: drop `brooklyn-dist` and put all of this stuff into

I'm with Mike on this one; 6 repositories - now 7 if there's a new one
for the Go CLI - risks overcomplicating things (and not just for

A top-level project for the distribution and odds and ends, plus
projects for "server", "web UI", "CLI" and "docs" is IMO acceptable -
to most observers it's a logical split and people would know where
they need to work. I'd accept "library" on the basis that we're trying
to obsolete it by having a catalog of pure-YAML blueprints, but I
suspect that it is going to hang around for quite a long time.


On 26 November 2015 at 01:44, Alex Heneveld
<> wrote:
> // migrating Mike's +0 comments to this thread
>> I think the proposed repo breakdown+organization is very logical, but my
>> concern is that it spreads everything out amongst too many repos,
>> potentially making it more difficult for newcomers to get a handle on
>> things and creating too many scenarios with groups of dependent PRs across
>> several repos.
> I'm glad you raised this.  I grew up with big codebase projects and have a
> soft spot for them for the reasons you bring up.  But there is a trend
> towards multiple smaller projects, and I've had a fair amount of feedback
> that the brooklyn codebase is big and hard to get to grips with.  While
> sub-projects will make it a little harder to get to grips with all of it,
> it should simplify a lot where someone wants to get to grips with a part of
> it.  And a potential contributor would be looking to contribute to just a
> part in the first instance.  You need to worry about the JS or Go projects
> if you're working on server; and (even simpler for a new start) someone
> working on the JS GUI or the Go client doesn't need to ever look at the
> server.
> The worst part I agree is likely to be the cross-project-PR-set but it
> should only hit someone making a complex change (esp the REST API and the
> JS or CLI client) -- thus the pain is reserved for us and (we hope!)
> alleviated for for everyone else.
> The best part I think will be encouraging independent JS UI development --
> where someone can run it with `grunt` pointing a binary-downloaded brooklyn
> and not have to rebuild server or touch java -- and the same for BOM yaml
> files in library.
> Best
> Alex
> On 25 November 2015 at 23:03, Alex Heneveld <
>> wrote:
>> Hi All-
>> Here is a summary of the recent "git repos" thread and online chat and
>> what we are currently proposing.  I will follow-up with a [VOTE] thread for
>> the creation of the repos and project migration.  Please reply to this
>> thread if you want to discuss; leave that thread for casting votes.
>> We are planning to request the following git repos, mirrored at
>>* :
>> * brooklyn - just pointers / summaries / scripts for working with the
>> other projects
>> * brooklyn-server - everythng to run the Brooklyn server (w REST API and
>> Karaf)
>> * brooklyn-client - CLI for accessing REST server (in go; subject of other
>> vote)
>> * brooklyn-ui - the JS GUI
>> * brooklyn-library - blueprints and tools which run on brooklyn-server
>> * brooklyn-docs - documentation (in markdown/ruby)
>> * brooklyn-dist - for building distros, incl source + binary tgz w all the
>> above
>> More detail of the content of these repos is below.
>> The motivation for this is so that people can check out smaller projects
>> and focus more easily on the pieces relevant to them.  IE someone working
>> on the UI or on the docs should not even need to look at server or dist.
>> In addition languages are consistent within projects.  There will be times
>> when a change necessitates PR's to multiple projects (e.g. new UI feature
>> with support in REST API) but we believe the above split will minimise that.
>> The addition of the *brooklyn-dist* project is the only change which has
>> not been discussed at some length but its need was obvious when we
>> discussed it.  (It would be possible to put it into *brooklyn* but that
>> would be rather confusing for people who land on that project and see a
>> bunch of code but nothing useful; if anything of substance were in
>> *brooklyn* people would probably expect it to be *brooklyn-server* which is
>> a possibility but the consensus has been that it is better to keep it
>> extremely light so as not to mask the other projects, any of which might be
>> what someone visiting would be interested in.)
>> There was also some discussion about the *brooklyn-server* project being
>> called *brooklyn-commons* instead.  The idea of a grassy commons is nice
>> but *server* is a more descriptive and accurate name (as most of the other
>> projects don't depend on it per se).
>> Other key points:
>> * The releases we make will continue to look the same:  the dist project
>> will make a single big source and big binary, and maven artifacts for all
>> maven projects.  Automation in the brooklyn project or the brooklyn-dist
>> project will build the projects in all the other repos to minimise the
>> impact of the multiple repositories.
>> * If we include a submodules setup in *brooklyn* it will be optional;
>> people who don't like submodules won't have to use them. We may instead
>> find that it is more convenient to provide scripts for working with the
>> other git modules.
>> * When we transfer the code to these repos we will exclude the offensive
>> big files in the history.  The incubator brooklyn repo will continue to
>> exist but we will mark it as deprecated forwarding to the new location.
>> IMPORTANT:  When we do this there will obviously be an impact on pull
>> requests and branch development.  We will endeavor to work through the PR
>> queue and we will give some notice before the changes.  If you miss this it
>> won't be hard to take diffs and apply them to the different structure but
>> it will be tedious!
>> Best
>> Alex
>> * brooklyn
>>     empty for now, contains a README and instructions/scripts for
>> subprojects;
>>     e.g. git submodules
>> * brooklyn-dist
>>     usage/all -> all
>> usage/dist -> dist
>>     usage/scripts -> scripts
>>     usage/downstream-parent
>>     usage/archetypes
>>     karaf (distro + other features - e.g. jsgui)
>>     ** new project brooklyn-server-cli which injects the JSGUI
>> * brooklyn-server
>>     parent
>>     api, core, policy
>>     util/*
>>     usage/rest-*
>>     camp/*
>>     usage/camp
>>     usage/cli -> usage/server-cli-abstract
>>         (assumes jsgui war is on classpath; injects into launcher)
>>     usage/logback-*
>>     usage/launcher (refactor so that WAR gets injected by server CLI)
>>     storage/hazelcast
>>     usage/qa
>>     usage/test-*
>>     karaf (code + itest + features needed for itest)
>> * brooklyn-ui
>>     jsgui
>> * brooklyn-client [subject of a separate vote]
>>     (new project, in go)
>> * brooklyn-library
>> software/*
>>     examples/*
>>     sandbox/* (?!)
>> * brooklyn-docs
>>     docs
>> END

View raw message