You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Francesco Furfari <fr...@isti.cnr.it> on 2006/05/02 20:01:07 UTC

Re: Dumb question

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 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
>>
>>
>>
>>
>>
>>
>>
>>   
>
>