Provide additional capability that includes the jvmName

[laeubi]

Currently a JustJ JRE already has a capability that allows to identify that it is a JustJ JRE, but not of what type (e.g. stripped).

This adds another capability that contains the jvmName

[merks]

FYI, here is an example of the model input:

https://download.eclipse.org/justj/jres/11/updates/release/11.0.23/justj.jregen

As such, JVM names are like this:

The MANIFEST also uses the JVM name in the BSN:

So the only difference it that BSN is qualified with the model name, i.e., with this:

All models provided by JustJ will have that name, even if we support graal or j9 in the future.

All this is to say, that I don't think it's useful to provide a capability with a truncated name because that provides effectively no additional value over using the BSN.

[laeubi]

Why I not want the "full" name is that it allows to be less specific, so instead of require one special JustJ (that might change in the future) I want to target a "variant".

Why I want a capability is because (similar to for example an Execution Environment) I don't want to target a specific provider but a provided "feature" (in this case a JRE).

[merks]

I just don’t see that requiring openjdk.hotspot.base instead of org.eclipse.justj.openjdk.hotspot.base is less specific but simply less verbose. After all, who else will ever provide that?

If we provided a capability with namespace org.eclipse.justj.type’ with name debugorstripped` then one could specify some aspect about the jre you want without being specific. See what I mean?

In other words, I would expect some capabilities that describe some aspect of the jre-providing bundle rather than providing some variant of the bsn.

[laeubi]

I just got the feeling that the name would be jre.base.strippedinstead of openjdk.hotspot.jre.base.stripped but that might be wrong... of course shorter is better I think :-)

Having a new capability seems fine as well but would require more adjustments, going that path one might even want a org.eclipse.justj.distribution (or vendor) (=temurin in this case?) so I see the advantage in that approach so if that's possible why not, I'm currently not able to guess how much effort it would be nor how to archive that...