You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Tim Moloney <t....@verizon.net> on 2008/03/25 02:25:12 UTC
Several easy questions
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?
- I list org.apache.felix.log, org.apache.felix.eventadmin, and
org.apache.felix.wireadmin as runtime dependencies for my bundle but
this doesn't appear to be necessary. What's "best practice" for this?
- Both org.apache.felix.log and org.apache.felix.wireadmin are at
version 0.9.0-SNAPSHOT. Will they be released as 1.0.0 anytime soon?
Thanks,
Tim
Re: Several easy questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> On 25/03/2008, Tim Moloney <t....@verizon.net> wrote:
>
>> Stuart McCulloch wrote:
>>
>>> On 25/03/2008, Tim Moloney <t....@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...
>
>
Re: Several easy questions
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Tim Moloney wrote:
> I think that I understand all of that. You have definitely given me a
> lot to think about.
Another thing to think about is that our maven bundle plugin makes it
easy for you to create bundles from other bundles, by embedding packages
from one into another. So, you don't necessarily have to think of the
compendium bundle, for example, as the definitive bundle for its API
packages. You could, if it made sense for your purposes, create separate
bundles that contain and export only the API that you need.
-> richard
>
> Thanks,
> Tim
>
> Stuart McCulloch wrote:
>> On 25/03/2008, Tim Moloney <t....@verizon.net> wrote:
>>
>>> Stuart McCulloch wrote:
>>>
>>>> On 25/03/2008, Tim Moloney <t....@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...
>>
>>
>>> so currently it needs the compendium bundle - or rather
>>>
>>>> any bundle that exports the wireadmin service package
>>>>
>>> I guess that I could always load the compendium bundle so that I have
>>> the API. Unfortunately, the compendium requires javax.servlet so I'll
>>> have to load that also even though I don't use it.
>>>
>>
>>
>> true - although the next release of the felix compendium
>> bundle will use DynamicImport-Package:* to avoid having
>> to pull in the javax.servlet package if you don't need it.
>>
>> ( the 1.0.0 release omitted this setting by mistake )
>>
>>
>>> 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 :)
>>
>>
>>> 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...
>>
>>
>
Re: Several easy questions
Posted by Tim Moloney <t....@verizon.net>.
I think that I understand all of that. You have definitely given me a
lot to think about.
Thanks,
Tim
Stuart McCulloch wrote:
> On 25/03/2008, Tim Moloney <t....@verizon.net> wrote:
>
>> Stuart McCulloch wrote:
>>
>>> On 25/03/2008, Tim Moloney <t....@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...
>
>
>> so currently it needs the compendium bundle - or rather
>>
>>> any bundle that exports the wireadmin service package
>>>
>> I guess that I could always load the compendium bundle so that I have
>> the API. Unfortunately, the compendium requires javax.servlet so I'll
>> have to load that also even though I don't use it.
>>
>
>
> true - although the next release of the felix compendium
> bundle will use DynamicImport-Package:* to avoid having
> to pull in the javax.servlet package if you don't need it.
>
> ( the 1.0.0 release omitted this setting by mistake )
>
>
>> 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 :)
>
>
>> 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...
>
>
Re: Several easy questions
Posted by Stuart McCulloch <st...@jayway.net>.
On 25/03/2008, Tim Moloney <t....@verizon.net> wrote:
>
> Stuart McCulloch wrote:
> > On 25/03/2008, Tim Moloney <t....@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...
> so currently it needs the compendium bundle - or rather
> > any bundle that exports the wireadmin service package
>
> I guess that I could always load the compendium bundle so that I have
> the API. Unfortunately, the compendium requires javax.servlet so I'll
> have to load that also even though I don't use it.
true - although the next release of the felix compendium
bundle will use DynamicImport-Package:* to avoid having
to pull in the javax.servlet package if you don't need it.
( the 1.0.0 release omitted this setting by mistake )
> 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 :)
> 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...
--
Cheers, Stuart
Re: Several easy questions
Posted by Tim Moloney <t....@verizon.net>.
Stuart McCulloch wrote:
> On 25/03/2008, Tim Moloney <t....@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.
> so currently it needs the compendium bundle - or rather
> any bundle that exports the wireadmin service package
>
I guess that I could always load the compendium bundle so that I have
the API. Unfortunately, the compendium requires javax.servlet so I'll
have to load that also even though I don't use it.
> 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.
> - I list org.apache.felix.log, org.apache.felix.eventadmin, and
>
>> org.apache.felix.wireadmin as runtime dependencies for my bundle but
>> this doesn't appear to be necessary. What's "best practice" for this?
>>
>
> you mean in maven?
Oops, yes, in Maven.
> 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?
> - Both org.apache.felix.log and org.apache.felix.wireadmin are at
>
>> version 0.9.0-SNAPSHOT. Will they be released as 1.0.0 anytime soon?
>>
>
>
> that's certainly the goal, but I can't give a firm date...
>
> Thanks,
>
>> Tim
>>
>> --
>>
> Cheers, Stuart
>
>
Thanks,
Tim
Re: Several easy questions
Posted by Stuart McCulloch <st...@jayway.net>.
On 25/03/2008, Tim Moloney <t....@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
so currently it needs the compendium bundle - or rather
any bundle that exports the wireadmin service package
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)
- I list org.apache.felix.log, org.apache.felix.eventadmin, and
> org.apache.felix.wireadmin as runtime dependencies for my bundle but
> this doesn't appear to be necessary. What's "best practice" for this?
you mean in maven? I typically only add the bundles
needed to compile against in the actual bundle pom
(a lot of the time just core+compendium) and list the
provisioned bundles separately with 'provided' scope
in another deployment file/pom
- Both org.apache.felix.log and org.apache.felix.wireadmin are at
> version 0.9.0-SNAPSHOT. Will they be released as 1.0.0 anytime soon?
that's certainly the goal, but I can't give a firm date...
Thanks,
>
> Tim
>
> --
Cheers, Stuart