Hi Neil, Thanks for the clarification. I have a better understanding of the topic now.
I think I should move my focus on easier tasks instead of looking at the base. On higher level bundles it should be easily possible to change from Require-Bundle to Import-Package. And the work Alex Blewitt started replacing Activators and IStartups seems also to be achievable. And yes I also think it is a question of the tooling how dependencies are managed. With bndtools a developer also specifies the dependencies in the .bnd file via a bundle (high level view of a tooling user) but the correct manifest is generated. Developers try to do the same with pde with a different result. But that is another discussion and I hope we find a solution for that also. :) Thanks, Dirk Am 30.10.2016 20:10 schrieb "Neil Bartlett" <[email protected]>: > 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
