[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] git migration for ECF
|
Hi Markus,
Markus Alexander Kuppe 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.
This (a wiki map of whatever repo structure we put in place) would be ok
with me, but like all else someone will have to develop/contribute such
a map.
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.
This is a tough question, IMHO. ECF now has several major components to
it...e.g. remote services certainly...but also presence, collaboration,
file transfer, telephony/voip, eclipse/tooling collaboration (think
real-time shared editing/cola/wave, etc), distributed state sync (which
underlies rt shared editing), multiple providers/protocols, applications
(twitter, newsreader, etc), server-side stuff, etc. Of course,
different consumers use different combinations of these parts...and so
partitioning them in a way that is most easily 'consumable' for all
consumers and use cases is a challenge.
I guess all I'm saying is that I would like to hear from others on the
organization that makes sense to them and would make it more
consumable. Since we committers (maybe me in particular) are a little
'biased' on how we organize things (just by knowing the existing
structure of things).
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?).
My inclination about this question (does everyone understand git repos
yet) is 'no'.
But the 'starter pack' notion seems like a pretty good one to me. I
think the trick is figuring out what set of starter packs to create,
based upon current (and future) use cases.
Scott
