Bugzilla – Full Text Bug Listing
| Summary: | Improve equinox service implementation dependencies to be more stand alone | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Thomas Watson <tjwatson> |
| Component: | Compendium | Assignee: | equinox.compendium-inbox <equinox.compendium-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | hargrave, jeffmcaffer, jwross |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | stalebug | ||
|
Description
Thomas Watson
Compendium implementation bundles from Equinox have been criticized for having too many external dependencies (compared with their counter parts from Felix). So much so that some OSGi instructors steer their students to the Felix bundles to simplify the class. One systemtic difference is in the tooling support used to build these bundles. Felix is built using bnd (in a maven plugin) which makes it very easy for a bundle to be packaged with a private copy of a java package. For example, org.eclipse.osgi.framework.eventmgr. The only value in importing this package is class file sharing at runtime. But there is no functional reason why the equinox.event bundle could not have its own copy to reduce the coupling to the framework/supplemental bundle. Since Eclipse builds with PDE and PDE does not have such functionality, we are limited to simply importing the package and taking the coupling. One can argue (as Tom does), that the changes requested here do not really add any useful function. But I think they do simplify people using these bundles if we reduce their coupling. (In reply to comment #1) > > One can argue (as Tom does), that the changes requested here do not really add > any useful function. But I think they do simplify people using these bundles if > we reduce their coupling. One can argue that our build process is not properly suited for copying packages into multiple bundles (which is true). But playing devil's advocate makes me question why maintaining a common package used by several bundles in a single bundle is not a good idea? If we are talking about a single class then I can understand the case to copy it to multiple bundles. But for more complicated "libraries" it seems sharing the package is a better idea. (In reply to comment #2) > One can argue that our build process is not properly suited for copying > packages into multiple bundles (which is true). But playing devil's advocate > makes me question why maintaining a common package used by several bundles in a > single bundle is not a good idea? If we are talking about a single class then > I can understand the case to copy it to multiple bundles. But for more > complicated "libraries" it seems sharing the package is a better idea. Sure, for a complicated libraries with several interconnected packages and which may share state you need to have people using the same package. But for packages which are nicely stand alone and have no shared state, you can have multiple copies to reduce coupling. Packages such as OSGi service packages can be placed in the bundle implementing the API. This really is not a sharing issue until multiple implementation bundles are installed. And with substitution and matching version constraints, we end up all using the same package. I think the idea of the org.eclipse.osgi.services bundle is a bad idea. It is essentially Eclipse's version of the osgi.cmpn jar which is intended as a compile-time jar and not a runtime bundle. Packages like org.eclipse.osgi.framework.eventmgr have no functional value in sharing. There is no functional reason why every bundle that uses this package cannot have its own private copy. But since we have no way in the build to have a single copy of the source code be packages as a built package in multiple bundles, we end up putting the package in a single bundle and others import it: increased coupling. I am NOT arguing for the current services bundle. However, your coupling point is interesting. The real problem with the current services bundle is that it is not cohesive. Lots of random stuff jammed into one bundle for convenience. From a coupling point of view, your suggestion of putting the API and implementation together seems more "against the OSGi ethos". It tightly couples the supplier of an API to the supplier of the implementation. If they are both in the same bundle then updating the implementation (and refreshing) causes all those wired to the API to be cycled when really only the users the service should see some service fluctuation. This could have huge and unnecessary ripples. It feels like the motivation for putting them together is to make it easy to deploy just one bundle and get a service working. I'm all for convenience but introducing that level of runtime/management coupling to facilitate shorter command lines seems counter-productive. Perhaps we just need better ways of manually installing services. Then OSGi itself could supply the relevant API bundles, one for each service interface, and everyone can consume them and supply implementations. (In reply to comment #4) > I am NOT arguing for the current services bundle. However, your coupling point > is interesting. The real problem with the current services bundle is that it is > not cohesive. Lots of random stuff jammed into one bundle for convenience. Yes, the services bundle is not cohesive. > From a coupling point of view, your suggestion of putting the API and > implementation together seems more "against the OSGi ethos". It tightly couples > the supplier of an API to the supplier of the implementation. If they are both > in the same bundle then updating the implementation (and refreshing) causes all > those wired to the API to be cycled when really only the users the service > should see some service fluctuation. This could have huge and unnecessary > ripples. This is not true. Putting the service API package in the implementation bundle includes using substitutable exports. This way if there are multiple implementation they can share the same package at runtime (assumes constraints, like versions, are met). Also, unless the packages are refreshed, the original exported service API package is still available after update. If there is no change to the service API package, there is no reason to refresh. > > It feels like the motivation for putting them together is to make it easy to > deploy just one bundle and get a service working. I'm all for convenience but > introducing that level of runtime/management coupling to facilitate shorter > command lines seems counter-productive. Feel free to ignore this bug. I am just relaying input from the trenches. But I am seeing the OSGi thought leaders (who are not Eclipse committers) moving to recommend Felix for some of the reasons outlined here. I just want Equinox to be the preferred (or at least equal) choice. > Perhaps we just need better ways of > manually installing services. Then OSGi itself could supply the relevant API > bundles, one for each service interface, and everyone can consume them and > supply implementations. OSGi supplies the source code and compiled class files for the service package. OSGi does not supply them packaged for runtime use. That is for others (like Equinox or Felix) to do. I don't expect this to change at OSGi. But someone can raise the discussion there. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |