On 25/03/2008, Tim Moloney <[EMAIL PROTECTED]> wrote:
Stuart McCulloch wrote:
On 25/03/2008, Tim Moloney <[EMAIL PROTECTED]> 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...
