| [equinox-dev] What to do about org.eclipse.osgi.services and org.eclipse.osgi.util bundles |
We have an ongoing discussion about what to do with the org.eclipse.osgi.services [1] and org.eclipse.osgi.util [2] bundles.
These have long been some awkward bundles to build and manage in source as well as at runtime.
1) We do not compile the Java code for these projects. Historically this has been because of circular class path issues between the packages needed for javax.microedition.io. But this causes major pains when built with CBI to generate source bundles [3]. Also other communities, such as linux (redhat) have a requirement to build all source. These communities have long struggled with how to build these bundles since our own build system does not actually compile the source code.
2) It is best practice in OSGi to package and export the OSGi service packages with the implementation instead of having these types of non-cohesive "API-only" bundles around.
The "right" thing to do is to stop shipping the org.eclipse.osgi.services and org.eclipse.osgi.util bundles altogether and to move the OSGi packages to the implementations bundles. The problem is the org.eclipse.osgi.services bundle is currently part of the RCP feature and org.eclipse.osgi.util is part of the platform feature. There could be applications today that use Require-Bundle to access OSGi packages out of these bundles. This would not be using OSGi best practices since these bundles export a bunch of unrelated API packages. There is no bundle that should want/need to have access to every package exported by this type of bundle. Instead bundles should be using Import-Package for the OSGi service and util packages. But removing the bundles will be considered a breaking change. So the question is, are we bound to live with these bundles without making any changes for all future releases or can we move forward and do the right thing in Luna to get the community to move to something that uses best practices?
Doing something in the middle to try and satisfy all will only make things worse in my opinion. It will involve multiple bundles in the common repository exporting the same packages so that we can keep the "API-only" bundles as well as package the OSGi API packages with the implementation bundles. I think this would cause unpredictable provisioning decisions to be made since it will be ambiguious which bundles will get pick as the provider of the packages. I think for the common repository we have always attempted to ensure duplicate packages are not contained in the repo. I would like to get some opinions in the org.eclipse.osgi.services bug [1]. If making any kind of breaking change is an absolute no-go then I would like to know now before spending much more time on this.
Thanks.
Tom
[1] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=411404
[2] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=411412
[3] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=407201