Christoph Läubrich

@bjhargrave can you review this? I have at least two external libs that would require multi-release support (and will see probably more in the future).

@bjhargrave please see the linked PR that shows how one can build a multi-release jar: https://github.com/laeubi/clickhouse-jdbc/blob/a75fec67450a9c9d1af4cdd58faee24258102c21/pom.xml#L583-L622 https://github.com/laeubi/clickhouse-jdbc/blob/a75fec67450a9c9d1af4cdd58faee24258102c21/pom.xml#L1006-L1022

> I still don't see any bnd file instructions. You don't see any because they are not required. > That PR also uses bnd-process mojo. What about all other places...

Please also note that the `` option might even be used if you not build a multi-release jar, but want to compile code for a specific release. Currently BND simply...

> My point is that all bnd configuration should be done through bnd instructions so that it can work in all places bnd is used. I can add a `-relase`flag...

> The next breaking changes may come with Bnd 7 when we move to Java 17 Then it seems a good opportunity to start with BND 7 right now. >...

> For proper multi-release support we do need to generate a partial manifest for each release folder, adding in dependency information for `Import-Package` and/or `Require-Bundle` This change actually support exactly...

This jar (need to rename to jar because of file type restrictions) is generated by BND with this change. It uses java 8, java 9 and java 11 alternative versions,...

It seems I was to enthusiastic here and more smaller steps are required, I therefore created: - https://github.com/bndtools/bnd/issues/5346 - https://github.com/bndtools/bnd/issues/5344 to track two aspects of this PR so they might...

@juergen-albert I don't think one needs to actually *compile* against an older version, but only check if the older version has a binary compatible method signature (something that bnd-baseline already...