Hi Dirk, Making the Eclipse Platform a better OSGi citizen is a nice idea but it’s very hard to do without breaking compatibility for all the thousands of existing plug-ins that use Require-Bundle to depend on the platform. Tom Watson and others on the Equinox project have already spent a lot of effort on exactly this goal, and have made significant improvements, but it’s probably not going to get any better than it already is. I doubt that I would be able to suggest anything that Tom had not already thought of.
Just to clear up one thing regarding the imports and exports (this was the question you originally asked on Twitter). There is no such thing as re-exporting a package that you have imported with Import-Package. There doesn’t need to be! If somebody is importing a package from your bundle then they might as well import it from the bundle you imported it from. When you see both “Import-Package: foo” and “Export-Package: foo” in the same Manifest, this is not a reexport, nor a self-import. It is *choice*. OSGi is permitted to use the Export-Package to provide the “foo” package to the framework, or it can use the Import-Package and allow your bundle to get “foo” from somewhere else. This is called a substitutable export; see the core spec section 3.6.6. Reexports are only relevant with Require-Bundle. You can either reexport all of the exports of the required bundle using the directive "visibility:=reexport", or you can individually export packages from the required bundle using your own Export-Package statement. Although I always say that Require-Bundle is bad, it is still the only way to deal with split packages. The key is to contain the badness within a small number of platform bundles so that not all Eclipse developers need to use Import-Package. For example you can use an aggregator bundle that uses R-B to pull together the parts of a split package and then reexports as a whole package. AFAIK that is pretty much what org.eclipse.core.runtime is doing. Finally, Bndtools is an existence proof that it is possible to write a complex Eclipse feature or app using only Import-Package… we do not use Require-Bundle in any part of Bndtools. I believe that the only real reason why Require-Bundle is still so widely used by Eclipse developers in the PDE tooling, which makes it nearly impossible to use Import-Package everywhere. This is why we develop Bndtools in Bndtools! Regards, Neil > On 30 Oct 2016, at 16:10, Dirk Fauth <[email protected]> wrote: > > 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 > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
