brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: [DISCUSS] new repos and project migration
Date Thu, 26 Nov 2015 01:44:23 GMT
// 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

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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message