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