[bnd] Support processing of Multi-Release-Jars #5346
Comments
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
|
I generally like this direction, however, I wonder if bnd could be even smarter than that. My question then would be @laeubi do you think there is a scenario where if bnd were able to automatically determine the applicable releases given a Jar's contents would that break something unexpectedly? |
Sure, the current approach is just as minimal and "dumb" as possible,mainly to not change too much and thus not requiring any (major) version bumps and my previous attempt even contained a list of discovered versions inside a jar, so one can think about the following:
So a "smart" way would be to assume we need:
but such an automatic approach would that requires much more attention e.g. for the analyzer it needs some kind of loop in "analyze", one for each release to be computed, and probably reset any cached states I don't know how good e.g. Analyzer plugins are prepared for multiple invocations with slightly different content returned. |
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
Currently bnd is not a capable of processing multi-release jars, this adds support of multi-release processing by a new directive -release where one can select what release version should be processed by bnd. Fixes bndtools#5346 Signed-off-by: Christoph Läubrich <laeubi@laeubi-soft.de>
|
Is there any progress planned on this issue? |
|
It is still on my work queue. I have a local feature branch but the work is still in progress. |
|
@HannesWell there is actually:
that already supports fully automated building of MR jars, there is even an example here: |
|
This multi Release jar thing is also a Blocker on our site. Some os project's love the multi release jars. They would accept bnd als build tool but its blocked by multi release support. |
There has been a long history how to support MRJs (Multi Release Jars). I kind of get it since it seems a giant magnet for complications, but alas, progress. The main problem with the current approach is that the support was focused on the Jar file. Imho, (and I think BJ's) this is the wrong place. The Jar abstracts working with the ZIP file but should imho not contain any semantics of the class path. We already placed the Bundle-Classpath (which is a very similar problem) in the Analyzer. This morning I had an interesting discussion with Christopher :-) He really helped me to see the problem more clear (I hope). I think we need to separate this problem strictly in 2 parts. The first is the MJR read support. This is this PR. Write will come later. During the discussion it became clear to me that for our build (remember, I am ignoring writing MJRs) we need a _view_ on the MJR that flattens the namespace of the resources. To be able to flatten, we need a max release for the view. I am a bit fuzzy on the use cases but I am convinced you need to be able specify this max release per JAR if you need to but for convenience, we need a setting per builder/project and default default. I've come up with the following rules: * In a -*path (e.g. -buildpath) you can set a MRJ. * You can add an attribute like `-java.release.max=10` to the file in the buildpath. This will create a view up to and including release 10. I.e. what the VM would see if it was a Java 10 VM. * In absence of this attribute, a default can be set in the workspace or project with the same property `-java.release.max=17` * In absence of a default, the Jar is flattened for all the release it contains. This may mean that the compiler cannot read certain class files. I am open to another strategy if someone has ideas. I am not sure I like the property name. We could use javac.target but I feel a tad uncomfortable with that. However, during the discussion it became crystal clear to me that this was not a Jar quality because the view that is used depends on the triplet of MRJ layout, max release, and the Jar. So I've implemented this accordingly in this PR. Quick feedback is appreciated because Christopher has been hanging in there for a very long time. --- Signed-off-by: Peter Kriens <Peter.Kriens@aQute.biz> Signed-off-by: Peter Kriens <Peter.Kriens@aQute.biz>
|
I am closing this as done. The test case for maven does not work yet but that is an open PR and does not seem to affect the current implementation |
This is related to
But only handles a subset, that is, support processing of Multi-Release-Jars.
Currently when one tries to process a Multi-Release-Jar with BND, the
bnd-maven-plugincomplains with the following message:The problem is, that BND currently do not read Multi-Release-Jar correctly leading to issues else where
One problem is, that Multi-Release-Jar processing requires to know what are the java release, this usually is taken from either the running VM or by specify it directly, e.g by a compiler switch.
Therefore I propose, as a first step, to allow specify a new directive in a bnd file
-releasethat takes an integer and is interpreted as the desired target release.BND should then work in the following way:
-releaseis specified, it should behave as of today, e.g. Multi-Release-Jars processing is disabled and might even lead to the current problems-releaseis specified and it is smaller than0it is interpreted as if it was not specified-releaseis specified and it is smaller than9it is interpreted as processing a jar with the default jar content that is ignoring anything fromMETA-INF/versionsand thus also don't find any modules info, or classes and do not complain-releaseis specified and it is larger or equal to9then it is interpreted as processing a jar with the given release, that is any class/resource inMETA-INF/versions/...that are smaller or equal to<release>will shade any class/resource from the default jar contentThis will ensure:
releaseoptionThe text was updated successfully, but these errors were encountered: