Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
From: Alex Heneveld <alex.heneveld@cloudsoftcorp.com>
Subject: Re: [DISCUSS] new repos and project migration
To: dev@brooklyn.apache.org, dev@brooklyn.incubator.apache.org
References: <56563E49.3010907@CloudsoftCorp.com>
 <CA+gmfahBTPDc_AGC+0Fx861ObbjLx122T8JhdThsFNyayC3ntg@mail.gmail.com>
 <CABQFKi2CfGFA1_rh_JFzXXWADtRxwLCxyFQn3PPVFOi2sd+S_w@mail.gmail.com>
 <565732AF.7090302@gmail.com>
 <CALwTLo4Aq+yNETNC2XVS1g6n-yytrvWfpbarCURKjF2CKFu6GQ@mail.gmail.com>
Message-ID: <56697E6C.9090607@CloudsoftCorp.com>
Date: Thu, 10 Dec 2015 13:30:20 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: 
 <CALwTLo4Aq+yNETNC2XVS1g6n-yytrvWfpbarCURKjF2CKFu6GQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


 > What if we have non-rest cli but a native java cli?

This would be a neat effort and would justify having a `brooklyn-base` 
and then a downstream `brooklyn-server`.  But we don't so currently 
`brooklyn-server` is to my mind the smallest useful packaging.

--A


On 09/12/2015 18:36, Valentin Aitken wrote:
> Hi,
>
> Better late than never :)
>
> I'd like to to vote -1 for the module brooklyn-server.
> I think brooklyn-base is a better name.
> brooklyn-server implies we should always have a server inside. What if we
> have non-rest cli but a native java cli?
>
> I am concerned a little about the build process. I suppose the build
> process shouldn't differ much from the current one.
> I imagine that we should have a shell script inside brooklyn-dist which
> downloads the dependent repositories and then compiling them in the same
> order.
>
> Valentin.
>
>
>
> On 26 November 2015 at 18:26, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
>
>> 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.
>>
>> Thanks,
>> Hadrian
>>
>>
>>
>> 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:
>>>
>>> LICENSE
>>> NOTICE
>>> README.md
>>> .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
>>> <alex.heneveld@cloudsoftcorp.com> 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 <
>>>> alex.heneveld@cloudsoftcorp.com
>>>>
>>>>> 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
>>>>> github.com/apache/* :
>>>>>
>>>>> * 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
>>>>>
>>>>>
>>>>>