brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <>
Subject Re: [DISCUSS] new repos and project migration
Date Thu, 26 Nov 2015 16:26:23 GMT
Before this thread looses its focus I want to clarify one point.

This [DISCUSS] is about how to move the *existing* code and history into 
separated repos. The rationale was giving by Alex Heneveld (and there is 
the side effect of not having to carry over the large binaries).

After that, how the code evolves, README files, .gitignore in each repo 
(obviously), etc, is a different story. Let's stay focus on the task at 
hand, necessary to complete the graduation and prepare the 0.9 release.


On 11/26/2015 06:12 AM, Richard Downer wrote:
> 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:
> .gitignore
> .gitattribues
> pom.xml
> All of these except pom.xml would also be present in every *other*
> repository, with minor modifications. This repo is not pulling its
> weight.
>> * 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
> `brooklyn`.
> 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
> newcomers).
> 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.
> Richard.
> 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