biz.aQute.bndlib dependency from PDE may conflict with future BND tools releases

[tjwatson]

With #536 PDE now pulls in some version of biz.aQute.bndlib. This may cause some conflicts when installing later versions of BND tools that want/need to ship a newer version of this bundle.

I noticed this while fixing bndtools/bnd#5783 in BND which was necessary to work around new split packages caused by eclipse-jdt/eclipse.jdt.ui#810. So I needed to build the current development branch of BND to test out my fix where I then install BND tools into my installation of the latest I-Build.

There I noticed that it took a really long time to restart Eclipse after installing the dev build of BND tools v7. It turns out that after installing my dev build of BND Tools there are now two versions of biz.aQute.bndlib:

478	RESOLVED    biz.aQute.bndlib_6.4.1.202306080939
858	RESOLVED    biz.aQute.bndlib_7.1.0.202309281339-SNAPSHOT

The resolver did manage to work out a valid resolution, without conflicts, but it took many minutes to do that. I also expect at some point the biz.aQute.bndlib version in a future release may end up not being compatible in some what which would then make it impossible to install without conflicts.

Could we instead embed the necessary packages from biz.aQute.bndlib into org.eclipse.pde.core such that it becomes an internal implementation detail? I think org.eclipse.pde.core is the only user of biz.aQute.bndlib in the Eclipse project. If we did that then there is no risk of future releases of BND tools conflicting with our dependency on biz.aQute.bndlib

[chrisrueger]

There I noticed that it took a really long time to restart Eclipse after installing

Ha, glad to read, that it is not just me. I noticed this effect (long one-time loading of Eclipse-restart after a bndtools update) also in the past (see here). Since it just happens once after updating bndtools (or installing bndtools in a fresh eclipse) I did not really care, because it was fast afterwards.

Anyway just wanted to mention this.

[HannesWell]

I have to admit that I'm a bit surprised that two versions of the bndlib are a problem.
In pde.core the bnd-packages are imported with proper version ranges and for pde.ui I just created #775 to do it as well. With that it looks like PDE does everything as it should do it from an OSGi perspective, isn't it?

Could we instead embed the necessary packages from biz.aQute.bndlib into org.eclipse.pde.core such that it becomes an internal implementation detail?

I would prefer to not copy sources from other libraries into PDE for the usual reason.
As soon as BND 7 is out I'm happy to upgrading PDE to it, raise the upper-bounds accordingly and also raise the lower bound where code-changes are necessary. If possible I'm also fine to be compatible with bnd 6 and 7.

I think org.eclipse.pde.core is the only user of biz.aQute.bndlib in the Eclipse project. If we did that then there is no risk of future releases of BND tools conflicting with our dependency on biz.aQute.bndlib

In M2E we are using bndlib as well, but I'm also fine to update there as well as soon as possible.

If you need some testing I can also try out the latest snapshot in conjunction with PDE and M2E next week.

[tjwatson]

I have to admit that I'm a bit surprised that two versions of the bndlib are a problem.

The problem is not at runtime. Rather it causes larger than necessary problem set for the resolver and it spends minutes trying to work it out.

I would prefer to not copy sources from other libraries into PDE for the usual reason.

I would not want to copy sources. What I am suggesting is include the library JAR (unchanged) on the Bundle-ClassPath or at build time include the .class files from the dependency directly and not to export the packages from the bundle so their use is isolated to PDE.

[laeubi]

With #536 PDE now pulls in some version of biz.aQute.bndlib. This may cause some conflicts when installing later versions of BND tools that want/need to ship a newer version of this bundle.

Can you explain where we have a conflict? Actually one advantage of OSGi is using different version of the same lib in one runtime.

There I noticed that it took a really long time to restart Eclipse

I noticed this not only with BND so actually I'm very often forced to use -Dequinox.resolver.revision.batch.size=1 I also think that the resolver uses the wrong strategy here, it should first use a batch-size of one and only if that do not work out try a larger (more complex) approach instead of the other way round.

So it would really be good to check why the resolver needs to perform that slow here, we already import-package with a range so it should be quite clear to narrow down things. Maybe #775 can help the resolver already...

I also expect at some point the biz.aQute.bndlib version in a future release may end up not being compatible in some what which would then make it impossible to install without conflicts.

Why? PDE does not export BND as part of its API and BNDTools claims to not using PDE at all so I don't see where there is a chance for conflicts.

Could we instead embed the necessary packages from biz.aQute.bndlib into org.eclipse.pde.core such that it becomes an internal implementation detail?

I would definitely vote against this. This complicates things a lot duplicates large jars (bndlib > 3 MB) and for the same reason we then must probably also embed biz.aQute.bnd.util and maybe others. Beside that the goal is to use bndlib on more places and this will further complicate things for no good reason (e.g. currently we would require to embedd BNDlib in pde.core **and pde.ui and both bundles won't be able to share any code)

I think org.eclipse.pde.core is the only user of biz.aQute.bndlib in the Eclipse project.

No, m2e is also using bndlib and pde.ui as well see above.

[tjwatson]

No, m2e is also using bndlib and pde.ui as well see above.

OK, then we have no choice.