Hi,

after the good talks and nice conversations at EclipseCon and OSGi
Community Event this year, I thought of trying to make the Eclipse Platform
code a "better OSGi citizen".

Unfortunately there seem to be some configurations that can't be solved
easily, namely split packages in very basic bundles. And the fact that
every change needs to consider to no break existing consumers.

As you probably know, in Eclipse RCP development (even in the Platform
itself) the usage of Require-Bundle is very common and widely used.
Additionally some bundles re-export the imported bundles. From what I have
read in the specification, re-exports can lead to startup performance
issues as ClassNotFoundExceptions can occur while searching a class down
the bundle dependency graph.

One of the first issues I came across was the org.eclipse.core.runtime
bundle and the org.eclipse.core.runtime split package.

There are some bundles in Equinox that also export org.eclipse.core.runtime
(e.g. org.eclipse.equinox.common). They specify a mandatory directive to be
able to deal with the split packages.
org.eclipse.core.runtime has Require-Bundle statements to that bundles and
exports the package without an attribute. So far it sounds to me like the
correct approach to deal with the split packages using an aggregator bundle.
Unfortunately org.eclipse.core.runtime requires several bundles and even
worse re-exports all of them.

I was asking myself if the bundle setup could be changed in a way that it
follows the OSGi best practices by still keeping the backwards
compatibility (people that are using Require-Bundle should not suffer from
changes but be able to go for the correct way).

First I wanted to change the Require-Bundle statements in
org.eclipse.core.runtime with proper Import-Package statements. But that
leads to issues with the split packages. The package needs to be imported
from several other bundles and then exported without a mandatory directive.
AFAIU that doesn't work as that would be multiple imports of the same
package (although different mandatory attributes). Correct?
Additionally I think there will be a backwards compatibility issue because
of the re-exports. For example via Require-Bundle
org.eclipse.equinox.common with re-export, the package
org.eclipse.equinox.event is also available by using Require-Bundle on
org.eclipse.core.runtime. So I thought of also exporting the package that
was imported. Surely not the best practice, I know. But I have seen that
Bndtools supports this while PDE is showing an error when this is tried. So
I'm also a bit confused whether that is allowed and supported (I think I
have seen this in the spec also) or if I misunderstand the re-exports.

While writing this I think I should not look at org.eclipse.core.runtime
but at the platform bundles that are consuming the bundle and change them
to use the correct Import-Package statements. But well, any insight and
opinions are welcome.

Greez,
Dirk
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to