felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff McAffer <Jeff_McAf...@ca.ibm.com>
Subject Re: Package naming conclusion
Date Thu, 18 Aug 2005 21:36:29 GMT
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.


"Richard S. Hall" <heavy@ungoverned.org> 
08/18/2005 01:28 PM
Please respond to


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.:


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message