Re: [ecf-dev] git migration for ECF

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 07/28/2010 07:46 PM, Scott Lewis wrote:
> The compendium module contains that ECF impl of OSGi remote services
> (which is part of OSGi compendium).  I'm not married to this
> organization, but loosely speaking it is how Equinox also structures
> things (they separate standards parts impl so that it's clear what's
> from core spec, what's from compendium, etc).

New adopters probably have a hard time finding their way through the
code base. If you don't know what server-side/, providers/ or
compendium/ stands for, you're lost. We might need something like a map
that takes you from the wiki to the code.

> Although I think that 2 makes some sense, it might result in a large
> number of separate modules...i.e. a very 'flat' structure...with many
> directories (i.e. one for each ECF api results in quite a few now). 
> This can/could be seen by others (particularly those unfamiliar with the
> project) as a complex structure...and therefore less
> approachable/understandable.
> 
> I don't know what the 'optimal' organization is...I'm just pointing out
> the trade-offs...i.e. more granularity (many directories at top level)
> can/could mean more perceived complexity...and I would like to keep
> things as approachable/understandable/simple as possible...both for
> those that know/are familiar with the API structure (i.e. existing
> committers) as well as others (contributors, community members,
> consumers, others).

Sounds to me as if we need to ask the question how new contributors tend
to approach the code base. Currently you just get a full copy of the
repo and then try to pick the pieces you are interested in. That's why I
like 2. better where one who is usually interested in a certain part of
ECF, gets something like a "starter pack" (probably not the best
naming), e.g.:

remoteservices/
remoteservices/framework
remoteservices/framework/o.e.e.remoteservices.rest
remoteservices/framework/o.e.e.remoteservices.soap
remoteservices/framework/o.e.e.remoteservices
remoteservices/protocols
remoteservices/protocols/ch.ethz.iks.r-osgi
remoteservices/providers
remoteservices/providers/o.e.e.provider1
remoteservices/providers/o.e.e.provider2
remoteservices/providers/o.e.e.provider3
remoteservices/tests
remoteservices/tests/o.e.e.test1
remoteservices/tests/o.e.e.test2
remoteservices/tests/o.e.e.test3
remoteservices/ui/o.e.e.remoteservice.ui
remoteservices/ui/o.e.e.remoteservice.ui.foo
remoteservices/ui/o.e.e.remoteservice.ui.bar
remoteservices/ui/o.e.e.remoteservice.ui...
remoteservices/features/o.e.e.remoteservice

With the extra benefit that smaller repos keep the history clean from
clutter that would originate from a different area of the project.

For extra comfort we might offer a superproject which aggregates all
"starter packs". Alternatively .psf files will do (do they understand
git repos yet?).

Markus