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