OSGi bundle's package structure

Question

I've been thinking some about "good practice" regarding package structure within osgi bundles. Currently, on average, we have like 8-12 classes per bundle. One of my initiative/proposal has been to have two packages; com.company_name.osgi.services.api (for api related classes/interfaces. (which is exported externally) and one package com.company_name.osgi.services.impl for implementation (not exported)). What are the pros cons about this? Any other suggestions?

Answer 1

It's not the number of classes that is important but the concepts. In my opinion you should have one conceptual entity in a bundle. In some cases this might be just a few classes in other several packages with 100s of classes.

What it important is that you separate the API and the implementation. One bundle contains the API of your concept and the other the implementation. Like this you can provide different implementations for a well defined API. In some cases this might be even necessary if you want to access the services from a bundle remotely (using e.g. R-OGSi)

The API bundles are then used by code sharing and the services from the implementation bundles by service sharing. Best way to explore those possibilities is to look at the ServiceTrackers.

Answer 2

You might also consider puting the interfaces in com.company_name.subsystem, and the implementation in com.company_name.subsystem.impl, the OSGI specific code, if there is any, could be in com.company_name.subsystem.osgi. Sometime you might have multiple implementation of the same interfaces. In this case you could consider - com.company_name.subsystem.impl1 and com.company_name.subsystem.impl2, for example:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

In this sense package structure could be OSGi agnostic, if you later on move to a different container, you just put an additional

com.company.scm.sca     // or whatever component model you might think of

Always having api and impl in your package name could be annoying. If in doubt use impl but not api.

Answer 3

In your case you could have the implementation in the same package, but all of its classes "package protected". This way, you can export the package and the implementation would not be visible to the outside, even when not using OSGi (but as a regular jar file).