// 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 <[email protected] > 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 > >
