Resolution View & Multi Release JARs

GENERAL
1

I thought by now I knew everything about Bndtools. However, this week did learn something about the Resolution View in bndtools that I was unaware off. This view was developed probably around 12 years ago by Neil Bartlett when he created support for the OSGi Resource or Capability/Requirement model in the user interface. When you select an item somewhere in the Eclipse user interface that can be mapped to a Resource, the Resolution View will show the myriad of requirements and capabilities in detail.

image
image1088×384 128 KB

When someone had a problem with the new Multi Release Jar (MRJ) support, it hit me that it might be interesting to use the Resolution View to inspect the MRJs. Alas, the View did not yet support the MRJs. To make the asinine idea of MRJs working in an environment that takes dependencies serious (unlike some module systems in Java I will not mention) it was necessary to introduce the concept of supporting resources. An MRJ is a chameleon where its color depends on the VM it runs on. Run it on Java 8 and it has dependency packages A and B. Run it on Java 17, and now it depends on package B and C. I.e. your modulepath and the VM command line instructions now depend on any MRJ in your assembly based on the VM release version. Goodbye easy upgrade. A certain amount of masochism must not be foreign to the originators of MRJ.

Anyway, the Resolution View did not show the supporting resources. I am still amazingly optimistic after 65 years so I decided to add them. When going through the code I discovered that the Resolution View, to my surprise, actually supported multiple selections. I distilled that the purpose was to do a mini resolving. By default you see all the requirements that cannot be resolved against the capabilities in the same view. By selection a set of resources in the Repository View, you can therefore quickly see what is missing.

There have been many a time where I manually added resources to a bndrun so I could figure this out.

Anyway, the Resolution View now supports the MRJs and I added the Repository as a possible selection, it adds all its resources.

If there is an overwhelming need I might be convinced to add some more features to help debugging resolution issues :slight_smile:

2 Likes
2

As I have repeatedly stated, the big problem of OSGi and its tooling is bad documentation. Have a look at the documentation for the resolution view (Bndtools). It’s empty! Would it be so hard for you as a long term expert to add your insights there instead of hiding them in some discussion where they can only be found with the help of some search engine if you happen to be lucky?

3

I agree the documentation could be better but it is a matter of money …

It is an open source project and I’ve donated tons of my own time in it but I still have to earn a living. As an experiment, I added sponsoring to bnd’s github account but I never got anything more than a derogatory smile about the pink heart …

4

It might help to lower the minimum amount:

image

5

Although it is a very nice gesture, bnd is not a consumer project where you could get by with many small one time donations. $128 is less than an hour of regular work and I highly doubt more than 10 programmers per year would donate ~$50. And I would not feel comfortable knowing that the money comes from the developer and not his company. For in general I find it is not the money but how open source has broken the link in companies between money and value; it made it much harder for developers to trade off their time vs tools and consultancy.

That said, I do appreciate the gesture but for this to work I think I need some kind of regular setup with a company where I can provide some extra value to the company. I.e. reviews, consultancy, expedited fixes, etc. I’ve such a contract with several companies but I am reaching cross roads and will have to make up my mind how I want to spend the last decade of my career.