Ok, I think we have finally reached some sort of conclusion about package naming. The majority of people [now] appear to feel that we should have "felix" in the package naming structure and it should be the root of everything, so that is how it will be.

However, some people have pointed out (blame Jeff McAffer) that it doesn't make sense to have "service" and "bundle" subpackages, since it is not necessarily easy to separate out bundle code and that this is really just a packaging issue any way and not something the programmer should be worrying about. I agree with Jeff's point and it is definitely true that just like using "osgi" in the package name is making a grand assumption, so is using "bundle".

From my understanding, Eclipse does not use a "bundle" subpackage, but they do use a "service" subpackage. However, (blame Jeff McAffer again) it is also clear that any interface could be a service interface, so it really doesn't make sense to have a "service" subpackage either.

To be the most flexible, I propose the following package structure (where o.a.f == org.apache.felix):

   o.a.f.framework // contains the framework impl
   o.a.f.<n> // everything else

So, in this case <n> could be a tool subproject, a bundle impl, or a service interface definition package. How they are bundled or whether they are bundled at all is a completely independent issue.

However, within the Felix project, we can follow a common approach for services and their impls, like:

   o.a.f.shell // contains service interface defs
   o.a.f.shell.impl // contains service impl
   o.a.f.shell.impl2 // contains alternate impl

The main benefit of this approach is that impls are logically related to their service interfaces and it doesn't pollute the o.a.f package as much. If a service is purely related to the framework, then its impl would go in the framework package, e.g.:

   o.a.f.framework.packageadmin

Or something similar.

The thing to be clear with here is that this is just a guideline for the Felix project and not a recommendation for how every other project must structure their bundles. There may even be cases within Felix where these guidelines cannot be followed, such as if a bundle implements two different service interfaces.

I hope everyone is happy with this compromise so that we can move on to fun things...not that this discussion hasn't been fun. ;-)

-> richard

Reply via email to