Re: [ecf-dev] git migration for ECF

[Wim Jongman <wim.jongman@xxxxxxxxx>]

Hi,

Marcus' ideas on the repo structure sound good to me. The compendium naming should be more a redirect than an official name IMHO. 

As a new member I was quite happy with the cvs structure and I think this way it will be even more clear. I also like the starter pack analogy. 

Regards

Wim


On Jul 28, 2010, at 21:53, Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:

> 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
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev