And here I was trying to stay out of this discussion... The only additional information I have to offer is - Eclipse uses "service" in the package names mostly out of a convention that the OSGi folks have been using for some time now - The conventions you set up will be followed by everyone (witness the previous point) - We tend to have the package names relate somehow to the symbolic id of the encapsulating bundle. This is just to help manage the namespace. Take a look at any Eclipse bundle for some examples.
Jeff "Richard S. Hall" <[EMAIL PROTECTED]> 08/18/2005 01:28 PM Please respond to oscar-dev To [email protected] cc Subject Package naming conclusion 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
