For a start, I am not against shorting the directory names to just the
unique portions of the actual package name.
I think we need to think more carefully about creating specific groups
around the concept of "bundle", since we original did shy away from this
since we decided that a "bundle" was merely a deployment unit and that
the subprojects could in fact be bundled up in various ways in the future.
However, that does not mean that we can not find some sort of
organization, even if we just call them "service-impls", "libraries", etc.
-> richard
Rob Walker wrote:
Was just chatting with Richard and he suggested I add my 10c here -
bear in mind, I'm neitger a maven or Apache old-hand here though, so
I'm aware I may be suggesting things that don't fit
* the long dir names on one hand look great, nice and important and
official looking. But on the other hand they're a pain to work
with, and the org.apache.felix trunk has a high level of redundancy.
* we must have re-org'd our dev. fs structures here a dozen times,
and it's never been perfect. What we have now is a flat 'project'
/ 'component' approach which works, and has limited redundancy in
naming - everything is a component of a project, even bundles that
are just 3rd party re-packaged JARs. Ok, in Felix terms I guess
this is more 'subproject' / 'component'
* In our model though, every component maps to exactly 1 bundle
which isn't the case in Felix - and I really used to like the old
Oscar model, where "bundle" components had their own separated area
So my vote would be something like a "subproject / component"
approach, with either one of the subprojects being "bundles", or a
separate bundles area which has it's own subproject/component
hierarchy underneath - of course if we need to we could further
subdivide OSGi standard bundles vs. other donated ones.
Of course all of these are heavily personal preferences, and I'm aware
others preferred structures will differ.
-- Rob
Richard S. Hall wrote:
Francesco Furfari wrote:
I have the same difficult ...but you suggest these changes because
you want easily install the bundles from a common location or
because you don't like such flat structure (or both ;-) ). In the
former case maybe it is possible to add some instructions to move
every bundle in a common directory ... without big changes to the
structure .... I'm just supposing :-)
It is a little bit of both...I don't like having so much in the
trunk, especially since all of the names are so long...you basically
get one column in 'ls' which is already scrolling off the screen.
Such hardships! :-)
-> richard
francesco
Richard S. Hall wrote:
I would like to see some reorganization of the repo, but I don't
know enough about it to do it myself. If someone wants to step up
and do some organizing, I think that would be great. I would love
to see all bundles being dropped into a common "bundle" directory.
-> richard
Francesco Furfari wrote:
Hi all,
I'm going to commit the rest of UPnP examples, this thread seems
me be concluded about the "Apache Felix " prefix, but what about
the re-organization proposed by Marcel?
I assume we are postponing any changes to the repo structure so
far ....
Regards
Francesco
Dennis Geurts wrote:
On Wed, 2006-04-05 at 17:17 +0200, Marcel Offermans wrote:
Furthermore, we might want to categorize the subprojects:
- framework;
- bundles;
- examples.
I can imagine you might want to build just the framework, or the
bundles, for example. Is that something that's possible and fits
in the "maven way of working"?
Greetings, Marcel
Marcel,
What you suggest is possible in mvn (if that infers it is a maven
way of
doing, I don't know)
Consider the following set-up: (bear with me)
/pom.xml <--packaging == pom, no
parent
/framework/pom.xml <--packaging == pom, parent
== /pom.xml
/framework/framework-main/pom.xml <--packaging == any, parent
== /framework/pom.xml
/framework/framework-util/pom.xml <--packaging == any, parent
== /framework/pom.xml
/framework/framework-optional/pom.xml <--packaging == any, parent
== /framework/pom.xml
/bundles/pom.xml <--packaging == pom, parent == /pom.xml
/bundles/bundle1/pom.xml <--packaging == osgi-bundle, parent
== /bundle/pom.xml
/bundles/bundle2/pom.xml <--packaging == osgi-bundle, parent
== /bundle/pom.xml
/bundles/bundle3/pom.xml <--packaging == osgi-bundle, parent
== /bundle/pom.xml
/bundles/bundle4/pom.xml <--packaging == osgi-bundle, parent
== /bundle/pom.xml
/examples/pom.xml <--packaging == pom, parent == /pom.xml
/examples/example1/pom.xml <--packaging == any, parent
== /examples/pom.xml
/examples/example2/pom.xml <--packaging == any, parent
== /examples/pom.xml
/examples/example3/pom.xml <--packaging == any, parent
== /examples/pom.xml
furthermore:
/pom.xml has modules: -framework
-bundles
-examples
/framework/pom.xml has modules:
-framework-main
-framework-util
-framework-optional
/bundles/pom.xml has modules
-bundle1
-bundle2
-bundle3
-bundle4
idem for examples
to build ALL targets, navigate to '/' and do mvn 'install' (or
any other
goal)
to build all 'framework' targets, navigate to '/framework' and do
'mvn
install' (or any other goal)
Greetings, Dennis
