Add support for reading Multi-Release-Jar content

[laeubi]

This adds methods to the Jar class to read versioned content of a
multi-release jar for the following cases:

• get a resource or a map of resources for a given release version
• get a merged manifest according to the OSGi specification
• get module name/version for a given given release version
• list all contained release alternative versions

Beside this a unit-test is added to cover these new functions.

Signed-off-by: Christoph Läubrich laeubi@laeubi-soft.de

[timothyjward]

Overall I think the direction is good, with just a few small fixes required to match spec behaviour.

I would be interested in seeing the aQute.bnd.build.model.EE updated to provide access to the release int for each EE.

[laeubi]

I have applied the suggested fixes and enhanced the test-case.

[laeubi]

I would be interested in seeing the aQute.bnd.build.model.EE updated to provide access to the release int for each EE.

If I understand the code correctly, this is simply EE.getCapabilityVersion().getMajor()

[timothyjward]

At this point I'm happy and think this is worth merging - @bjhargrave do you have anything to add?

[timothyjward]

If I understand the code correctly, this is simply EE.getCapabilityVersion().getMajor()

Yes, although the following isn't exactly readable...

EE myEE = getResolveTargetEE();
manifest = jar.getManifest(myEE.getCapabilityVersion().getMajor()).get();

[laeubi]

I think it won't be a problem to add a new "getRelease()" method here, but lets see first if there is other to do.

[laeubi]

thanks @timothyjward for the review, the Ci is also happy!

[laeubi]

Yes, although the following isn't exactly readable...

EE myEE = getResolveTargetEE();
manifest = jar.getManifest(myEE.getCapabilityVersion().getMajor()).get();

I have opened

• Add EE.getReleaseTarget() method #5358

for this as it seems to be a valid enhancement regardless of MR support...

[laeubi]

@bjhargrave I have now created two PRs based on this to show how one can uses the Multi-Release-Jar support to:

• Correctly handle JPMS module info: [jpms] Fix calculation of module name with mult-release-jar dependencies #5360
• Create a Multi-Release-Bundle by specify Multi-Release: true in the BND instructions: Add support for building multi-release jars (automatic!) #5359

I hope this i sufficient to review this PR and decide if changes are required before this can be merged.

FYI @stbischof @rotty3000

[timothyjward]

The following comment is wrong. The version should be 17 for the third check in the test.

https://github.com/bndtools/bnd/compare/2d1a4c6ba66197105067b44814b5c4033f6f7a0d..9856c6cbda183da1a08ee1a8fd1dbaa77a76e090#diff-5ba9b2d89cbd966cfd1655fb0c9488599e851bc6ae563e20bfd63c9df4e0d93aR152

[laeubi]

The version should be 17 for the third check in the test.

Fixed!

[timothyjward]

@bjhargrave - I think that this should be merged, can we go ahead?

[laeubi]

@rotty3000 can you maybe help here? Its about a full month now with no feedback at all ... :-\

[bjhargrave]

I am still working on ideas about mrjar support in a side branch based upon the narrative in https://github.com/bndtools/bnd/wiki/Multi-release-JAR-support-design-discussion. Sorry it is taking awhile but have other items to also work on.

Until I have a better idea on how we should handle mrjars, I don't want to merge this partial proposal.

[laeubi]

So now after about half a year later is there any decision / progress on this?

[pkriens]

@laeubi can you contact me via Peter.Kriens@aQute.biz? I'd like to have a zoom call to understand all this. I've kept myself out of this discussion (I am not convinced multi release jars are even remotely a good idea, they seem to suffer a lot of accidental complexity) but now with BJ out of the loop I need to get this of the PR list. So if you can contact me, we setup a call.

[laeubi]

@pkriens I send you a mail, I think the main point is not if one likes MR or not, that's not a desiccation made by the tool, I just wanted to support it because more and more libs are start using this and it is part of the OSGi Spec for many years, but yes it might not be used much. That's also why I aim for a quite basic solution as a first step and from my testing with this it works quite good for the rare cases where I needed a MR jar (mostly to add OSGi headers to a 3rd party library).

[pkriens]

I will take over this PR