felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Several easy questions
Date Tue, 25 Mar 2008 13:12:08 GMT
Stuart McCulloch wrote:
> On 25/03/2008, Tim Moloney <t.moloney@verizon.net> wrote:
>   
>> Stuart McCulloch wrote:
>>     
>>> On 25/03/2008, Tim Moloney <t.moloney@verizon.net> wrote:
>>>
>>>       
>>>> I have created a simple bundle that uses org.apache.felix.log and
>>>> org.apache.felix.eventadmin.  Although I build against
>>>> org.osgi.compendium (for the interface definitions), I can run without
>>>> it.  I just started using org.apache.felix.wireadmin in my bundle and
>>>>         
>> it
>>     
>>>> requires compendium  to be running in the framework.
>>>>
>>>> - Should org.osgi.compendium be running in the framework to run
>>>> org.apache.felix.wireadmin?
>>>>
>>>>         
>>> the wireadmin bundle needs the wireadmin service API
>>> which is provided by the compendium bundle - I guess
>>> it could embed this API for convenience (and then both
>>> import and export it, in case the compendium bundle is
>>> already loaded) but I don't think the spec mandates this
>>>       
>> Wouldn't it make sense that a bundle that implements a service, export
>> that interface?  I think that org.apache.felix.log and
>> org.apache.felix.eventadmin both do this.
>>     
>
>
> this isn't mandated by the spec - yes, it is convenient for
> bundles implementing a service to contain and export the
> API - but this also means more duplication, slightly larger
> bundles, and potentially makes it harder to swap bundles
> while the system is up and running
>
> for example, if I publish the API in one bundle and put the
> implementation in another then consumers will be wired to
> the API bundle. I can then swap various implementations
> in and out without disturbing the bundles wired to the API
>
> this also means it's easier to unload implementations as
> the implementation classloader won't be kept alive by the
> API references, because they're in a separate bundle...
>   

The above is a good explanation of the trade-offs you must consider when 
packaging your bundles...there is no single perfect way.

>> btw, you may find your bundle can run fine without the
>>     
>>> compendium bundle if it doesn't get round to invoking
>>> code that needs the API (or if it happens to embed it)
>>>       
>
> Would it be a good idea for my bundle to include (as private packages)
>   
>> any interfaces it uses?  This way, my bundle won't have any failed
>> dependencies.  I can then gracefully handle any missing services rather
>> than failing to load.
>>     
>
>
> if you do decide to include the APIs inside your bundle then
> (regardless of whether you export them) please make sure
> you import them, otherwise you will see class cast issues
> when your bundle is used on a system which includes the
> compendium bundle
>
> always import APIs even if you contain and/or export them
>
> personally, I prefer to keep APIs in a separate bundle as
> I find this more flexible - but if you want to keep bundles
> down to a minimum then embedding the API is fine, as
> long as you're careful with your imports and exports :)
>   

The approach Tim suggests will only work if you both import AND export 
the APIs. If you only import, then you will not resolve if they are not 
present. If you only export, then you will only see your private copies.

You could also use a dynamic import of the API package.

-> richard

>   
>> I typically only add the bundles
>>     
>>> needed to compile against in the actual bundle pom
>>> (a lot of the time just core+compendium)
>>>       
>> I understand this part.
>>
>>     
>>> and list the
>>> provisioned bundles separately with 'provided' scope
>>> in another deployment file/pom
>>>
>>>       
>>   I don't understand this.  Can you elaborate?
>>     
>
>
> well, I do a lot of demos/practicals so I use scripts
> and archetypes to quickly create bundle projects
> - google "Pax-Construct" if you're interested
>
> the generated projects have a separate pom under
> a "provision" directory where I list the bundles that
> are to be deployed/provisioned along with the local
> compiled/wrapped bundles.
>
> the maven-pax-plugin scans the bundle poms and
> this provision pom to determine which bundles are
> to be deployed onto the framework - any optional
> dependencies are ignored and won't be provisioned
>
> it then creates a "deployment" pom that is passed
> onto Pax-Runner to do the actual deployment
>
> this means I can compile against one set of bundles
> (marked as optional in the bundle pom) and deploy
> against a different set (listed in the provision pom)
>
> I could even add maven profiles to the provision pom
> to support deploying against different sets of bundles
> - it's very flexible...
>
>   

Mime
View raw message