I think it really depends.

Using the org.osgi.service.log package as an example, this package is 
small, contains mostly interfaces and a few small classes (exceptions, 
events, ...). These classes have very little implementation and change 
very slowly. This package is suitable for all three choices but (3) is 
probably overkill.

For servlet API, I would go with (3) for several reasons. 

(a) The code contains non-trivial implementation in places that may need 
fixing. Its own bundle allows it to be independently updated.
(b) The code is from a 3rd party. The servlet code comes from a different 
source than the http service implementation (most likely the case). 
Therefore clean seperation makes sense. I have contributed code to make a 
servlet 2.1 bundle for Felix. So this will one day be available as a 
bundle direct from Apache.
(c)The code is not just a small  package. There is quite a but of code so 
(2) will consume resources unnecesarily if there are several bundles all 
providing the package.
(d) Since the code is 3rd party, it is probably on different release 
schedules that the code which is using it. So (1) is a poor choice here.


In summary, I generally prefer (2) or (3). (2) is great for small service 
packages. (3) is better for package with some implementation complexity or 
size. (1) is really just a packaging optimization that may be done too 
early :-)

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Jeff McAffer <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
2006-01-29 03:58 PM
Please respond to
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>


To
OSGi Developer Mail List <osgi-dev@bundles.osgi.org>
cc

Subject
[osgi-dev] Where should API go?







At the risk of exposing some religion... 

There seems to be quite a bit of debate on where to put API packages 
relative to their implementation(s).  The current one on hand for us is 
the javax.servlet API and the HTTP service implemenation.  (see 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=121585 if you want the gory 
details). 

Here is the scenario 
   org.eclipse.osgi.services -- All the OSGi produced API packages.  This 
includes the HTTP service API 
   org.eclipse.equinox.http -- implements the HTTP service but needs 
javax.servlet 

The question for this example is, "where should the javax.servlet packages 
be put?"  Three options 

1) in the services bundle 
+ convenient and efficient (no extra classloaders assuming you have to 
have services anyway) 
- bloats the services bundle 
- does not scale on disk.  Everyone else will want to put their stuff in 
there too. 
- drags in other interfaces 

2) in the http service impl bundle 
+ convenient and efficient (no extra classloaders) 
- brittle as it ties the implementation to the packages.  If you update 
the HTTP bundle the old one cannot be tossed until a restart.  This keeps 
around all the impl classes 
- causes problems for folks that want to use the service if it is 
available but are ok if it isn't.  That is, they have to spec an import to 
get the service interface but if the interface is only available via 
implementations, they have to have an implementation to resolve. 

3) in a third bundle just for the servlet API (e.g., javax.servlet) 
+ clear 
- adds another classloader.  i.e., does not scale well at runtime if 
everyone takes this approach 
- how big should these bundles be?  The Services bundle only makes sense 
because its contents are all from the same source and the interfaces are 
very small.  Otherwise many of the contents are completely unrelated. 
- harder to manage as you have more bundles (this may be a nit but 
depending on how much you put in each, there could be alot of API bundles) 


I have seen Peter state that #2 is a VERY [his empahsis] common approach 
and was somewhat surprised by that.  The Knopflerfish folks seem to have 
all three approaches (in some cases for the same function). 

We just need to pick a path and do it.  Any advice would be most 
appreciated. 

Jeff _______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev


_______________________________________________
osgi-dev mailing list
osgi-dev@bundles.osgi.org
http://bundles.osgi.org/mailman/listinfo/osgi-dev

Reply via email to