You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Richard S. Hall" <he...@ungoverned.org> on 2006/04/05 16:33:20 UTC
Dumb question
Looking at the maven result list:
[INFO]
----------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
----------------------------------------------------------------------------
[INFO] Apache Felix (parent) .................................. SUCCESS
[2.057s]
[INFO] Maven OSGi Plugin ...................................... SUCCESS
[3.268s]
[INFO] Servlet 2.1 API ........................................ SUCCESS
[1.044s]
[INFO] OSGi R4 Core Bundle .................................... SUCCESS
[0.882s]
[INFO] OSGi R4 Compendium Bundle .............................. SUCCESS
[1.321s]
[INFO] Apache Felix Shell Service ............................. SUCCESS
[0.754s]
[INFO] Apache Felix OSGi Framework Implementation ............. SUCCESS
[1.925s]
[INFO] Apache Felix Shell Text Interface ...................... SUCCESS
[0.609s]
[INFO] Apache Felix Shell GUI ................................. SUCCESS
[0.578s]
[INFO] Apache Felix Bundle Repository Service ................. SUCCESS
[1.093s]
[INFO] Apache Felix Shell GUI Plugin .......................... SUCCESS
[1.066s]
[INFO] Apache Felix Daemon .................................... SUCCESS
[0.544s]
[INFO] Apache Felix Dependency Manager ........................ SUCCESS
[0.878s]
[INFO] Apache Felix Main ...................................... SUCCESS
[0.874s]
[INFO] Apache Felix Examples: Service Event Listener .......... SUCCESS
[0.381s]
[INFO] Apache Felix Examples: English Dictionary Service ...... SUCCESS
[0.619s]
[INFO] Apache Felix Examples: French Dictionary Service ....... SUCCESS
[0.390s]
[INFO] Apache Felix Examples: Dictionary Client ............... SUCCESS
[0.652s]
[INFO] Apache Felix Examples: Dynamic Dictionary Client ....... SUCCESS
[0.438s]
[INFO] Apache Felix Examples: Spell Check Service ............. SUCCESS
[0.456s]
[INFO] Apache Felix Examples: Spell Check Client .............. SUCCESS
[0.404s]
[INFO] Apache Felix Service Binder ............................ SUCCESS
[0.956s]
[INFO] Apache Felix Examples: Spell Check w/ Service Binder ... SUCCESS
[0.405s]
[INFO] Apache Felix WireAdmin ................................. SUCCESS
[0.926s]
[INFO] Apache Felix UPnP Extra ................................ SUCCESS
[0.573s]
[INFO] Apache Felix UPnP Sample TV ............................ SUCCESS
[0.909s]
[INFO]
----------------------------------------------------------------------------
It strikes me, is it 100% necessary to include the "Apache Felix" prefix
on everything? Seems somewhat redundant to me. Is this a standard way to
do things or are we just mimicking it because someone else did it in the
repo?
I propose we axe the prefix, then we can have simpler names that will
hopefully match the Bundle-Name, where simple is nice, since we can use
the Bundle-Name when installing bundles from obr (i.e., "obr deploy
ShellService").
Thoughts?
-> richard
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Enrique Rodriguez wrote:
>> I propose we axe the prefix, then we can have simpler names that will
>> hopefully match the Bundle-Name, where simple is nice, since we can use
>> the Bundle-Name when installing bundles from obr (i.e., "obr deploy
>> ShellService").
>>
>> Thoughts?
>>
>
> How would "namespace conflicts" be handled? Meaning, what prevents
> more than 1 ShellService?
>
I assume you are talking about conflicts when using OBR with other
repos. In that case, you can use the bundle symbolic name instead of the
bundle name...or use a GUI. :-)
This will be an issue, so it is something to consider.
-> richard
Re: Dumb question
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/5/06, Richard S. Hall <he...@ungoverned.org> wrote:
> It strikes me, is it 100% necessary to include the "Apache Felix" prefix
> on everything? Seems somewhat redundant to me. Is this a standard way to
> do things or are we just mimicking it because someone else did it in the
> repo?
In my case I mimicked what was there, and I am indifferent about
having the prefix or not.
> I propose we axe the prefix, then we can have simpler names that will
> hopefully match the Bundle-Name, where simple is nice, since we can use
> the Bundle-Name when installing bundles from obr (i.e., "obr deploy
> ShellService").
>
> Thoughts?
How would "namespace conflicts" be handled? Meaning, what prevents
more than 1 ShellService?
Enrique
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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"?
Yes, I agree that it would be nice if it were possible to break this up
somehow. I find it fairly difficult to work with it already and I
imagine it will only get worse.
-> richard
Re: Dumb question
Posted by Enrique Rodriguez <en...@gmail.com>.
On 4/5/06, Marcel Offermans <ma...@luminis.nl> 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"?
Your grouping makes sense. We have quite a few bundles more coming in
RSN, which will exacerbate this issue.
Enrique
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stefano Lenzi wrote:
> Francesco Furfari wrote:
>
>> about the grouping we also have some example and I maintained the same
>> package structure we used in Domoware:
>> (bundle) org.apache.felix.upnp.basedriver
>> (bundle) org.apache.felix.upnp.extra
>> (tool) org.apache.felix.upnp.tester
>> (example) org.apache.felix.upnp.sample.tv
>> (example) org.apache.felix.upnp.sample.clock
>> (example) org.apache.felix.upnp.sample.binaryLight
>>
>>
>> I wonder if the examples should be "bundled" with the bundles or not.
>> bundles->example vs examples->bundle
>>
>>
> I think that will be nice to have a group for each type of bundle that
> we have inside felix, so that all example can be inside a directory and
> the same for core/compendium bundle, and so on.
>
Do you mean the project directories are all inside one directory or that
the resulting JAR files are inside a single directory? Personally, I
find it annoying that all of the generated bundle JAR files are all in
their separate target/ directories. Makes it a pain if you want to
install some of them into the framework...especially with all of the
long file names.
-> richard
Re: Dumb question
Posted by Stefano Lenzi <ki...@interfree.it>.
Francesco Furfari wrote:
>>
> about the grouping we also have some example and I maintained the same
> package structure we used in Domoware:
> (bundle) org.apache.felix.upnp.basedriver
> (bundle) org.apache.felix.upnp.extra
> (tool) org.apache.felix.upnp.tester
> (example) org.apache.felix.upnp.sample.tv
> (example) org.apache.felix.upnp.sample.clock
> (example) org.apache.felix.upnp.sample.binaryLight
>
>
> I wonder if the examples should be "bundled" with the bundles or not.
> bundles->example vs examples->bundle
>
I think that will be nice to have a group for each type of bundle that
we have inside felix, so that all example can be inside a directory and
the same for core/compendium bundle, and so on.
Re: Dumb question
Posted by Francesco Furfari <fr...@isti.cnr.it>.
>
> I just mimicked what was there,
me too :)
> Furthermore, we might want to categorize the subprojects:
> - framework;
> - bundles;
> - examples.
>
about the grouping we also have some example and I maintained the same
package structure we used in Domoware:
(bundle) org.apache.felix.upnp.basedriver
(bundle) org.apache.felix.upnp.extra
(tool) org.apache.felix.upnp.tester
(example) org.apache.felix.upnp.sample.tv
(example) org.apache.felix.upnp.sample.clock
(example) org.apache.felix.upnp.sample.binaryLight
I wonder if the examples should be "bundled" with the bundles or not.
bundles->example vs examples->bundle
It's true that we'll integrate UPnP examples with other OSGi service,
for instance using the HTTPservice in order to implement the
Presentation aspects of UPnP devices, but on the contrary if somebody is
interested to UPnP only it could be a tedious work do a search or also
build all the examples.
francesco
Re: Dumb question
Posted by Alex Karasulu <ao...@bellsouth.net>.
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! :-)
This is the price to pay for using the package name for the module name
which does not necessarily have to be that way. You can still name the
artifact with the package name to follow the eclipse bundle naming style
and use short names for the module. It's really up to you. Personally
I don't like this scheme at all. It sounded good when it was proposed
but it's definitely an issue for working with the command line. With
similar prefixes (pkg names) I can't even use shell tab completion properly.
Alex
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: Dumb question
Posted by Rob Walker <ro...@ascert.com>.
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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>
--
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>
>
Re: Dumb question
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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 :-)
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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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
>>
>>
>>
>>
>>
>>
>>
>>
>
>
Re: Dumb question
Posted by Francesco Furfari <fr...@isti.cnr.it>.
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
>
>
>
>
>
>
>
>
Re: Dumb question
Posted by Dennis Geurts <de...@luminis.nl>.
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
Re: Dumb question
Posted by Marcel Offermans <ma...@luminis.nl>.
Richard S. Hall wrote:
> It strikes me, is it 100% necessary to include the "Apache Felix"
> prefix on everything? Seems somewhat redundant to me. Is this a
> standard way to do things or are we just mimicking it because someone
> else did it in the repo?
I just mimicked what was there, but I agree with your suggestion to drop
the prefix if we can.
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
Re: Dumb question
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Alex Karasulu wrote:
> I put these prefixes for module names because that's what m2 uses by
> default for html page titles while generating the site. It seems like
> the prefix is superfluous but it makes for a better looking generated
> site. It also helps with search engines. I learned this the hard way.
Very good points, indeed.
Well, I think keeping them is okay if there are some benefits to doing so.
Perhaps the question to ask then, is there a relationship between the
project name and the bundle name when the project is a bundle? Are they
the same or independent?
Keeping them the same seems to make the most sense. However, in places
where we might try to use the bundle name as a handle or ID, then we end
up with a longer handle, such as OBR. As Enrique pointed out, though,
this does have some benefit for name clashes, although this may not be a
major issue for now.
-> richard
Re: Dumb question
Posted by Alex Karasulu <ao...@bellsouth.net>.
Richard S. Hall wrote:
> Looking at the maven result list:
>
> [INFO]
> ----------------------------------------------------------------------------
>
> [INFO] Reactor Summary:
> [INFO]
> ----------------------------------------------------------------------------
>
> [INFO] Apache Felix (parent) ..................................
> SUCCESS [2.057s]
> [INFO] Maven OSGi Plugin ......................................
> SUCCESS [3.268s]
> [INFO] Servlet 2.1 API ........................................
> SUCCESS [1.044s]
> [INFO] OSGi R4 Core Bundle ....................................
> SUCCESS [0.882s]
> [INFO] OSGi R4 Compendium Bundle ..............................
> SUCCESS [1.321s]
> [INFO] Apache Felix Shell Service .............................
> SUCCESS [0.754s]
> [INFO] Apache Felix OSGi Framework Implementation .............
> SUCCESS [1.925s]
> [INFO] Apache Felix Shell Text Interface ......................
> SUCCESS [0.609s]
> [INFO] Apache Felix Shell GUI .................................
> SUCCESS [0.578s]
> [INFO] Apache Felix Bundle Repository Service .................
> SUCCESS [1.093s]
> [INFO] Apache Felix Shell GUI Plugin ..........................
> SUCCESS [1.066s]
> [INFO] Apache Felix Daemon ....................................
> SUCCESS [0.544s]
> [INFO] Apache Felix Dependency Manager ........................
> SUCCESS [0.878s]
> [INFO] Apache Felix Main ......................................
> SUCCESS [0.874s]
> [INFO] Apache Felix Examples: Service Event Listener ..........
> SUCCESS [0.381s]
> [INFO] Apache Felix Examples: English Dictionary Service ......
> SUCCESS [0.619s]
> [INFO] Apache Felix Examples: French Dictionary Service .......
> SUCCESS [0.390s]
> [INFO] Apache Felix Examples: Dictionary Client ...............
> SUCCESS [0.652s]
> [INFO] Apache Felix Examples: Dynamic Dictionary Client .......
> SUCCESS [0.438s]
> [INFO] Apache Felix Examples: Spell Check Service .............
> SUCCESS [0.456s]
> [INFO] Apache Felix Examples: Spell Check Client ..............
> SUCCESS [0.404s]
> [INFO] Apache Felix Service Binder ............................
> SUCCESS [0.956s]
> [INFO] Apache Felix Examples: Spell Check w/ Service Binder ...
> SUCCESS [0.405s]
> [INFO] Apache Felix WireAdmin .................................
> SUCCESS [0.926s]
> [INFO] Apache Felix UPnP Extra ................................
> SUCCESS [0.573s]
> [INFO] Apache Felix UPnP Sample TV ............................
> SUCCESS [0.909s]
> [INFO]
> ----------------------------------------------------------------------------
>
>
>
> It strikes me, is it 100% necessary to include the "Apache Felix"
> prefix on everything? Seems somewhat redundant to me. Is this a
> standard way to do things or are we just mimicking it because someone
> else did it in the repo?
>
> I propose we axe the prefix, then we can have simpler names that will
> hopefully match the Bundle-Name, where simple is nice, since we can
> use the Bundle-Name when installing bundles from obr (i.e., "obr
> deploy ShellService").
>
> Thoughts?
I put these prefixes for module names because that's what m2 uses by
default for html page titles while generating the site. It seems like
the prefix is superfluous but it makes for a better looking generated
site. It also helps with search engines. I learned this the hard way.
Alex