Bundles with osgi.ee filter for Java version 1.1 or 1.0 are not resolved

[HannesWell]

Bundles that require the following capabilities are not resolved, neither in the Target-Platform nor in the workspace because such capability is not provided:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.1))"

Using version=1.0 does not resolve as well, while version=1.2 resolves.
One real world example that requires this capability is org.apache.xml.resolver from the screenshot which is used (transitively) by org.apache.xerces, org.eclipse.wst.xml.core and finally m2e.

@tjwatson is this the case because org.eclipse.osgi does not contain a profile for JavaSE/J2SE in version 1.0 and 1.1?
And what is the way to solve this issue. Should Equinox/PDE support such old Java versions as minimum requirement or should the bundle be fixed?
It looks like that variant of xml.resolver is build by Eclipse Orbit, so that should be changeable relatively simply:
https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/org.apache.xml.resolver_1.2.0

[merks]

As far as I can tell, the following on the release train resolve to such older versions:

But the a.jre.javase IU(s) must be present to provide those capabilities.

The Oomph bundle has this as the BREE:

Bundle-RequiredExecutionEnvironment: JRE-1.1

In your case, which repositories are present and do they provide the a.jre.javase IUs?

[HannesWell]

As far as I can tell, the following on the release train resolve to such older versions:

Thanks for that hint. Which view is the screenshot from?

In your case, which repositories are present and do they provide the a.jre.javase IUs?

I'm using the m2e target-platform:
https://github.com/eclipse-m2e/m2e-core/blob/master/target-platform/target-platform.target

Simply adding unit a.jre.javase did not help here.

But I noticed that according to Oomph's Repository explorer view (besides many others) the m2e-release repos provide the osgi.ee JavaSE version 1.0.0 and 1.1.0. If this is correct it should also be available in the workspace (unless Tycho is adding that to the m2e-repo):

[merks]

Sorry, the view I show is work-in-progress analysis tools that will be part of this:

https://github.com/eclipse-cbi/p2repo-aggregator

I tried to reproduce the issue but was not able to do so. Here I've resolved exactly a copy of the TP in your link without a problem:

[HannesWell]

Sorry, the view I show is work-in-progress analysis tools that will be part of this:

https://github.com/eclipse-cbi/p2repo-aggregator

Ah Thanks. The reason I'm asking is that such detailed analysis is difficult with standard-PDE views and there are three different views in PDE to show the bundles in the TargetPlatform: Target Platform State, Plug-in Registry and Plugins view that all offer slightly different information. And I think it would be good to merge them into one, maybe even with the Features view, and to enhance them in order to simplify requirements/provision analysis.
Did you consider to contribute such view to PDE?

I tried to reproduce the issue but was not able to do so. Here I've resolved exactly a copy of the TP in your link without a problem:

Hmm. Strange. Maybe it depends on the installed JRE? I'm using my local Java-11 GraalVM installation:

I assume you use JustJ? Maybe the installed features provide more osgi.ee capabilities than regular Java installation?

[merks]

The analysis tool depends significantly on the very cool infrastructure in the aggregator repository so it would not be easy to "move" this to PDE. In the end. such analysis is primarily p2 functionality, not PDE functionality...

I'm not sure if the outcome could be affected by the JRE/JDK being used. It should depend purely on what p2 metadata is available. I'm my case I was using C:\Program Files\Java\jdk-11.0.13+8:

openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment Temurin-11.0.13+8 (build 11.0.13+8)
OpenJDK 64-Bit Server VM Temurin-11.0.13+8 (build 11.0.13+8, mixed mode)

[laeubi]

Bundles that require the following capabilities are not resolved, neither in the Target-Platform nor in the workspace because such capability is not provided:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.1))"

I can only repeat from the tycho discussion, I don't think that is (&(osgi.ee=JavaSE)(version=1.1)) nor 1.2 would valid according to http://docs.osgi.org/reference/eenames.html it has to use the name J2SE vor versions prior to 1.6.

[jcompagner]

and i think for 1.1 we even need JRE not J2SE, if i look at the profile list in the osgi jar of eclipse:

[laeubi]

and i think for 1.1 we even need JRE not J2SE, if i look at the profile list in the osgi jar of eclipse:

Actually it does not makes any sense given that Eclipse requires Java 11 (!) to put any effort in to declare a EE of any Java 1.1/1.2 so simply using JavaSE-1.6 would be sufficient.

[merks]

The bundles involved are ones that could be used in any OSGi environment, so not supporting something that is a valid OSGi constraint seems questionable...

[laeubi]

Then they should use EE=OSGi/Minimum anyways Orbit is for supporting Eclipse Projects and as soon as you show me the eclipse project still running on Java 1.1 there might be a "Question" otherwise its just a theoretical "support" without any value...

[iloveeclipse]

and as soon as you show me the eclipse project still running on Java 1.1 there might be a "Question" otherwise its just a theoretical "support" without any value...

I think this is generated automatically, at least for my case of org.apache.xml.resolver.
If I see it right, from https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/org.apache.xml.resolver_1.2.0 :

In generated MANIFEST.MF inside org.apache.xml.resolver 1.2.0.v20220401-1849 note the Created-By and version date:

Created-By: Eclipse Bundle Recipe Maven Plug-in
Built-By: default
Build-Jdk: 11.0.13
...
Bundle-Version: 1.2.0.v20220401-1849
...
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.1))"

So questions:

1. who is Eclipse Bundle Recipe Maven Plug-in ?
2. why does it generate 1.1 ?
3. why should PDE not support Java 1.1 if we run on 11?

beside this, there are tons of existing libraries written before Java 11 was born and saying they support Java 1.x. Why should they be touched only to make PDE happy?

[jcompagner]

the question i have is, why do they need to add that capability in the first place?
What does that gain? (even if it has the correct value) loads and loads of jars in eclipse don't have that.
i guess that is also now something they wonder here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=580280

[laeubi]

Well, PDE don't care, Tycho don't care, OSGI don't care as 1.2 is a compatible replacement for 1.1... still people complain, that PDE emits a warning that org.apache.xml.resolver uses something that do not makes sense from its POV, that is requiring that you can run this bundle on Java 1.1 (!), so for sure one can now put additional effort in "supporting" Java 1.1 (Release date February 1997) in PDE or just either put 1.6 there or OSGi/Minimum or whatever here in as this is completely irrelevant as even OSGi itself says Java 1.2 (!) is a minimum to implement a compliant OSGi framework.

why does it generate 1.1 ?

BND reads it from the java classes and you can simply override it here:
https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/org.apache.xml.resolver_1.2.0/osgi.bnd

[laeubi]

the question i have is, why do they need to add that capability in the first place?

This is to states what is the java runtime you need to start this bundle, so a bundle with incompatible EE (e.g. java 17 on java 11 framework) do not gets resolved and fails with missing classes, or incompatible class versions.

[laeubi]

and i think for 1.1 we even need JRE-1.1

This seems link a Equinox specific extension to me.

[akurtakov]

So questions:

1. who is `Eclipse Bundle Recipe Maven Plug-in` ?

https://github.com/eclipse/ebr/tree/master/releng/maven-plugins

2. why does it generate `1.1` ?

Should be asked at https://github.com/eclipse/ebr/issues

3. why should PDE not support Java 1.1 if we run on 11?

As per http://docs.osgi.org/reference/eenames.html JavaSE-1.1 is not valid BREE thus osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.1))" is not valid one too. Why is a question for OSGi spec guys as none of us here can answer it. Equinox has it's specific workaround but it seems to be osgi.ee;filter:="(&(osgi.ee=JRE)(version=1.1))" as per https://github.com/eclipse-equinox/equinox/blob/master/bundles/org.eclipse.osgi/JRE-1.1.profile#L21

[jcompagner]

the question i have is, why do they need to add that capability in the first place?

This is to states what is the java runtime you need to start this bundle, so a bundle with incompatible EE (e.g. java 17 on java 11 framework) do not gets resolved and fails with missing classes, or incompatible class versions.

i can't believe that that apache xml will run at java 1.1 ;)

i didn't look but what java is it compiled against/with? my guess is that would be at least 1.7 maybe 1.6 ...

I know that it is needed to say which java runtime you need, but still, a lot of other jars that eclipse bundles (almost all) don't have that osgi.ee thing.. i think only some core eclipse plugins, but most "normal" plugin jars don't have that.

Besides that what we also have: Bundle-RequiredExecutionEnvironment: JavaSE-11
and that is used by many (at least the jars that are really first class eclipse plugins)

[laeubi]

i can't believe that that apache xml will run at java 1.1 ;)

It might just be that this particular jar is compiled with class version 1.1 but I haven't checked that.

I know that it is needed to say which java runtime you need, but still, a lot of other jars that eclipse bundles (almost all) don't have that osgi.ee thing.. i think only some core eclipse plugins, but most "normal" plugin jars don't have that.

Most eclipse jar still use the Bundle-RequiredExecutionEnvironment but that is deprecated.

[HannesWell]

Thank you for the heads up and the investigation.
Since the osgi.ee filter is invalid, I agree that this is not a PDE issue and will close it as invalid.

For my M2E I just locally added xerces:xercesImpl:2.12.2 respectively xml-resolver:xml-resolver:1.2 via a Maven target and unfortunately both are not OSGi ready. I let the M2E Maven-target generate the OSGi Manifest.MF (which uses bnd-lib 6.3.1) and this created the following osgi.ee filter which resolves successfully:
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JRE)(version=1.1))"

So the solution for this problem is either to ask Apache to make those project OSGi ready and to publish new versions or we have to stick with Orbit and have to fix eclipse-ebr to create valid metadata and then to publish a new version of org.apache.xml.resolver (maybe 1.2.1).

[vogella]

So the solution for this problem is either to ask Apache to make those project OSGi ready and to publish new versions or we have to stick with Orbit and have to fix eclipse-ebr to create valid metadata and then to publish a new version of org.apache.xml.resolver (maybe 1.2.1).

Or use direct M2E PDE integration for this library instead of the broken Orbit version.

[HannesWell]

So the solution for this problem is either to ask Apache to make those project OSGi ready and to publish new versions or we have to stick with Orbit and have to fix eclipse-ebr to create valid metadata and then to publish a new version of org.apache.xml.resolver (maybe 1.2.1).

Or use direct M2E PDE integration for this library instead of the broken Orbit version.

If projects do that, they should ensure that those wrapped bundles are not included in any published p2-repo. Otherwise there would be a risk that different projects add the same bundle with a different auto-generated name. IIRC Orbit was still the preferred way for such cases (and given the provided artifact is then valid).

[jcompagner]

just a question here, who are the maintainers for: https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/httpcomponents/org.apache.httpcomponents.client5.httpclient5-win_5.1.2/osgi.bnd#n10

is there an issue tracker?

or is there just the email list?

i asked this because the http components are still adusted by Orbit (they should ask apache todo that once so that they are providing the correct osgi meta data). But that slf4j api is wrong.. that should not generated [1.7.25,2) (so not including 2)
we need support for 2 and 2 is binary compartible

[akurtakov]

just a question here, who are the maintainers for: https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/apache/httpcomponents/org.apache.httpcomponents.client5.httpclient5-win_5.1.2/osgi.bnd#n10

is there an issue tracker?

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Orbit

or is there just the email list?

i asked this because the http components are still adusted by Orbit (they should ask apache todo that once so that they are providing the correct osgi meta data). But that slf4j api is wrong.. that should not generated [1.7.25,2) (so not including 2) we need support for 2 and 2 is binary compartible

Only way to get the change in speedy way is to provide gerrit patch IMHO.

[HannesWell]

i asked this because the http components are still adusted by Orbit (they should ask apache todo that once so that they are providing the correct osgi meta data). But that slf4j api is wrong.. that should not generated [1.7.25,2) (so not including 2) we need support for 2 and 2 is binary compartible

In case you are interested, there is an umbrella issue for Eclipse-Platform to migrate to SLF4J from Maven-Central and SLF4J-2:
eclipse-platform/eclipse.platform.releng.aggregator#588
Any help to make dependencies ready is welcome.

[laeubi]

i asked this because the http components are still adusted by Orbit (they should ask apache todo that once so that they are providing the correct osgi meta data).

Why should "they" ask Apache to do something why can't "you" ask Apache or even better just provide a patch for them?

But that slf4j api is wrong.. that should not generated [1.7.25,2) (so not including 2)
we need support for 2 and 2 is binary compartible

I don't think it is binary compatible as it requires Java 1.8 but should be Consumer API compatible:

there are no client facing API changes in 2.0.x. For most users, upgrading to version 2.0..x should be a drop-in replacement, as long as the logging provider is updated as well.

https://www.slf4j.org/faq.html#changesInVersion200

[HannesWell]

i asked this because the http components are still adusted by Orbit (they should ask apache todo that once so that they are providing the correct osgi meta data).

Why should "they" ask Apache to do something why can't "you" ask Apache or even better just provide a patch for them?

There was already an attempt about a year ago, but it was rejected:
apache/httpcomponents-client#284

But it could be tried again respectively their concerns could be addressed.

But I suggest we discuss slf4j upgrades in eclipse-platform/eclipse.platform.releng.aggregator#588.

[jcompagner]

i tried it again yes: https://issues.apache.org/jira/browse/HTTPCORE-725

but they are not really into it.. i don't get it almost all other apache projects (from commons to log4j and so on) are all fine as far as i know except this HC libs. its not really rocket science and i think there are already tools which can generate stuff that are a bit more dynamic right?

SLF4J says its binary compartiable over all releases, and i tried it already with the httpclient and you can switch between 1.7.x and 2.0.x just fine it works fine.

But the Orbit guys already did it: https://git.eclipse.org/r/c/orbit/orbit-recipes/+/196310
this https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1941/artifact/releng/repository-all/target/repository/plugins/ now generates the right stuff.

[laeubi]

@akurtakov I'm wondering who at platform uses that httpclient? And is there any genuine feature we need so we cannot simply migrate to https://docs.oracle.com/en/java/javase/11/docs/api/java.net.http/java/net/http/HttpClient.html ?

[akurtakov]

Platform doesn't use it directly. It comes as a dependency of ECF which P2 uses for transport.

[laeubi]

Platform doesn't use it directly. It comes as a dependency of ECF which P2 uses for transport.

Thanks, I have created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=580896

[HannesWell]

i tried it again yes: https://issues.apache.org/jira/browse/HTTPCORE-725

Thank you @jcompagner for your help on this topic.

Platform doesn't use it directly. It comes as a dependency of ECF which P2 uses for transport.

Thanks, I have created: https://bugs.eclipse.org/bugs/show_bug.cgi?id=580896

ECF is also on GitHub now and you can create issues there, just in case you want to continue on this.
@jcompagner also asked to for an updated SLF4J there:
eclipse/ecf#11

I don't think it is binary compatible as it requires Java 1.8 but should be Consumer API compatible:

there are no client facing API changes in 2.0.x. For most users, upgrading to version 2.0..x should be a drop-in replacement, as long as the logging provider is updated as well.

https://www.slf4j.org/faq.html#changesInVersion200

But the next section https://www.slf4j.org/faq.html#compatibility explicitly states:

Code compiled with slf4j-api-versionN.jar will work with slf4j-api-versionM.jar for any versionN and any versionM. To date, binary compatibility in slf4j-api has never been broken.

I'm not sure if this is really tested/ensured or is just a bit sloppy statement. And I'm not such much familiar with the details of binary-compatibility that I can judge it.

[akurtakov]

Please don't hijack this issue for slf4j updates.