You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Valentin Aitken <va...@cloudsoftcorp.com> on 2015/12/09 19:36:49 UTC
Re: [DISCUSS] new repos and project migration
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 <hz...@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
>> <al...@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
>>>>
>>>>
>>>>
Re: [DISCUSS] new repos and project migration
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
> 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 <hz...@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
>>> <al...@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
>>>>>
>>>>>
>>>>>