Java 8 & Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"

Question

I have using Eclipse Luna win32.x86_64 runing with Java 8.

Here from the Help Menu > About > Installation Detail > Configuration Tab:

java.runtime.version=1.8.0_05-b13
java.version=1.8.0_05

I have created new plug-in project, requesting JavaSE-1.8 as Execution Environment:

Plug-in Editor. JavaSE-1.8 as Execution Environment

In the myplugin/META-INF/MANIFEST.MF file I have of course:

 Bundle-RequiredExecutionEnvironment: JavaSE-1.8

I use this plugin in a product file. When I try to validate it, I get following error:

Validations Dialog, opened from the product file editor

Of course if I start the product, I get:

!ENTRY org.eclipse.osgi 2 0 2014-07-10 08:14:22.042
!MESSAGE One or more bundles are not resolved because the following root constraints are not resolved:
!SUBENTRY 1 org.eclipse.osgi 2 0 2014-07-10 08:14:22.043
!MESSAGE Bundle update@********/myplugin/ was not resolved.
!SUBENTRY 2 myplugin 2 0 2014-07-10 08:14:22.044
!MESSAGE Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))".

I have tried to verify a lot:

Preferences > Java > Installed JREs

Installed JREs

Preferences > Java > Installed JREs > Excution Environments

Excution Environments

Preferences > Java > Compiler: JDK Compliance Compiler compliance level

Compiler

When I start the product, I checked in the Launching tab that I use the jre8 as execution environment.

I have even tried to change the Java Runtime Environment in the Run Configurations Dialog:

Java Runtime Environment

I have tried different settings. None of them works.

What is wrong?

Is it a known issue?

score 23 · Accepted Answer · edited Aug 08 '17 at 22:39

23

The error means that your bundle has a Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" entry in its manifest. So this means the bundle will only start when there is a bundle that provides this capability.

In case of the osgi.ee capability it is the OSGi framework (equinox) that should provide this capability. Apparently it does not do this.

So one approach would be to remove the header from you bundle Manifest. The other would be to make equinox export the capability. Perhaps you could simply try with the newest equinox version. Not sure if this helps though. You could also try to set the framework property (using -D): org.osgi.framework.system.capabilities=osgi.ee; osgi.ee="JavaSE";version:List="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"

See

The same problem on the eclipse list

edited Aug 08 '17 at 22:39

Chin

19,717
37
107
164

answered Jul 10 '14 at 09:47

Christian Schneider

19,420
2
39
64

1

Thank you... You are right I have an old Juno Equinox in my target platform. – Jmini Jul 10 '14 at 12:37
I have Mars.1 Release (4.5.1) Build id: 20150924-1200 and this error still appears. What worked was what Christian mentioned as a first option: open META-INF/MANIFEST.MF and under "Execution Environments" remove JavaSE-1.8 or replace it with JavaSE-1.7 and after I exported ("hello world") application it started without problems. – nidalpres Oct 27 '15 at 02:34
2

I have this issue with Java10. Where can the framework poperty be set? Somewhere in the run configuraiton for the Eclipse Application? – Stefan Apr 25 '18 at 09:51

score 19 · Answer 2 · edited Dec 15 '15 at 16:15

Sharing my experience on retrofitting a target platform based on Juno 3.8.2 to run JUnit plugin tests with Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8:

Failed approach 1: Fragment

Creating a fragment to org.eclipse.osgi with a Provide-Capability header in the manifest:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: FrwJava8Support
Bundle-SymbolicName: frwJava8Support
Bundle-Version: 1.0.0.qualifier
Fragment-Host: org.eclipse.osgi;bundle-version="3.8.2"
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Provide-Capability: osgi.ee;osgi.ee="JavaSE";version:List="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"

This capability was never picked up.

Failed approach 2: Startup parameter

Using -Dorg.osgi.framework.system.capabilities as outlined in Christian's answer.

First of all, the argument must be quoted correctly:

-Dorg.osgi.framework.system.capabilities="osgi.ee; osgi.ee=\"JavaSE\";version:List=\"1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8\""

This approach might have worked for any other use case other than pde.junit. I still got this (slightly different) exception:

!MESSAGE Bundle com.XXX.tst.frw.common_1.0.0.qualifier [92] was not   resolved.
!SUBENTRY 2 com.XXX.tst.frw.common 2 0 2015-04-18 13:43:55.336
!MESSAGE Missing Constraint: Bundle-RequiredExecutionEnvironment: JavaSE-1.8
!SUBENTRY 1 org.eclipse.osgi 2 0 2015-04-18 13:43:55.336
!MESSAGE Bundle com.XXX.tst.frw.common.test_1.0.0.qualifier [101] was not resolved.
!SUBENTRY 2 com.XXX.tst.frw.common.test 2 0 2015-04-18 13:43:55.336
!MESSAGE Missing host com.XXX.tst.frw.common_1.0.0.

!ENTRY org.eclipse.osgi 4 0 2015-04-18 13:43:55.336
!MESSAGE Application error
!STACK 1
java.lang.IllegalArgumentException: Bundle "com.XXX.tst.frw.common" not found. Possible causes include missing dependencies, too restrictive version ranges, or a non-matching required execution environment.
    at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.getClassLoader(RemotePluginTestRunner.java:77)

Working approach 3: Patch Equinox

Patch the org.eclipse.osgi bundle to include Luna's JavaSE-1.8.profile.

Copy file <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile to your target platform bundle pool's org.eclipse.osgi bundle.
(e.g. <myworkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.osgi_3.8.2.v20130124-134944.jar\JavaSE-1.8.profile)
Reference profile in profile.list (actually, this seems to be optional):
add JavaSE-1.8.profile,\ to .metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.osgi_3.8.2.v20130124-134944.jar\profile.list

However, this solution requires hosting your own P2 repository containing the org.eclipse.osgi bundle or applying a patch to every workspace's bundle pool.

Discussion

Still, there exists the possibility to keep BREE at "JavaSE-1.7" that is compatible with the existing org.eclipse.osgi 3.8.2 version.

I am currently aware of two drawbacks:

Exporting plugins directly from Eclipse via PDE fails if Java 8 syntax is used in the code (e.g. lambda expressions).
Log contains compiler errors and compiled result is actually of different size compared to a bundle compiled with JavaSE-1.8 BREE.

Presumably, PDE evaluates BREE and sets compiler source level accordingly which then results in "1.7" for Java 8 sources. It is possible that other PDE features (feature export, product export) might exhibit same problem.

Using Eclipse Tycho, it is possible to manually override the javac source level instead of evaluating a bundle's BREE (to select a JDK to compile with). However, also Tycho still matches the given source level vs. BREE and refuses to compile Java 8 code (tested with Tycho 0.22).

Also, approach 2 will most likely not work with PDE's bundle export, at least I am not aware of any possibility to pass VM arguments.

Update 29.05.2015

We went with approach 3 and successfully patched our target platform to use Java 8 together with Eclipse 3.8.

As we already maintain our own P2 repository with all 3.8-based Eclipse plugins, we needed to:

create an updated copy of org.eclipse.osgi (needed to strip signing information from bundle as well)
create a feature patch that patches org.eclipse.rcp feature with updated org.eclipse.osgi bundle
publish new 3.8-based P2 repository to be consumed by our workstations and build server.

Summary

If you maintain your own P2 repository to serve a custom target platform instead of using any Eclipse.org-based update site, it is possible to make Eclipse 3.8 work with Java 8.

References: Eclipse Bug to support osgi.ee

For legacy products, this is a much better solution than removing the required headers and hoping for the best, or messing around with start up params. — hiergiltdiestfu, Dec 17 '15 at 07:01
Thanks for the answer!. I used the approach 3 as well and it works for our command line PDE build of RCP application based on 3.8.2. However, for me updating the ```profile.list``` file was mandatory. — Ivan Senic, May 31 '17 at 10:17
One question, we followed the approach 3, but now the PDE build can not compile files that are in java 1.8 source level (f.e. lambda expressions). Seams that PDE build properties javacSource=1.8 and javacTarget=1.8 are ignored completely. Any suggestions on this? — Ivan Senic, Aug 18 '17 at 12:15
sorry, we are using Maven Tycho for builds. Did you try to set the bundle's BREE (Bundle Required Execution Environment) to 1.8 in MANIFEST.MF? — Henrik Steudel, Aug 22 '17 at 17:51
We did, does not work. I guess a patch is needed somewhere, but we can not find a place. Any additional ideas? — Ivan Senic, Aug 25 '17 at 08:05
Works for us! I have uploaded a patched 3.8.2 osgi lib: https://github.com/hacki11/osgi-3.8.2-jre1.8 — Juergen, Feb 16 '18 at 08:14

score 4 · Answer 3 · answered Nov 17 '16 at 22:40

4

An easy fix is to include org.eclipse.equinox.ds (equinox declarative services). That runtime bundle exports the required osgi.extender and appears to trigger no additional dependencies.

answered Nov 17 '16 at 22:40

andrew glynn

81
2

Here org.eclipse.equinox.ds has a dependency on org.apache.felix.scr. Adding the later fixed the issue. – ocroquette Jun 26 '17 at 21:49
had to manually add ```org.eclipse.equinox.event``` besides ```org.eclipse.equinox.ds``` – lolung Apr 14 '19 at 19:26
```Add Required Plug-ins``` seems to be broken: https://bugs.eclipse.org/bugs/show_bug.cgi?id=494913 – lolung Apr 15 '19 at 07:21

score 3 · Answer 4 · answered Sep 28 '16 at 08:52

I found a configuration that just works, without much work. You select Java 8 in product file, project settings and build path. The important thing is the manifest file. Here you have to select both Java 8 and Java 7. Here also the order is important. Java 8 has to be on top.

I think the reason why this configuration is working is that the compiler selects the first JRE and so can handle the new syntax of Java 8. The eclipse bundles check if one of the entries is the needed Java 7 and are also satisfied.

Thank you VERY Much for this tip. I think this may have been the answer I was looking for! — atom88, Jan 05 '18 at 21:45

score 1 · Answer 5 · edited Feb 13 '18 at 03:24

I found the problem in the Felix 5.6.10 version that was causing my issue:

"Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"

This is the code that creates the problem. It is in the constructor of the ExtensionManager

String pkgextra =
        "true".equalsIgnoreCase(configProps.getProperty(FelixConstants.USE_PROPERTY_SUBSTITUTION_IN_SYSTEMPACKAGES)) ?
            Util.getPropertyWithSubs(configProps, FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA) :
            configProps.getProperty(FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA);
    syspkgs = ((pkgextra == null) || (pkgextra.trim().length() == 0))
        ? syspkgs : syspkgs + (pkgextra.trim().startsWith(",") ? pkgextra : "," + pkgextra);

changed the last line to:

    syspkgs = ((pkgextra == null) || (pkgextra.trim().length() == 0))
        ? syspkgs : syspkgs + (pkgextra.trim().startsWith(",") ? pkgextra.substring(1) : pkgextra);

the reason it causes a problem is that a little further on in the constructor we find this code:

try
{
    ManifestParser mp = new ManifestParser(
        m_logger, m_configMap, m_systemBundleRevision, m_headerMap);
    List<BundleCapability> caps = aliasSymbolicName(mp.getCapabilities());
    caps.add(buildNativeCapabilites());
    appendCapabilities(caps);
}
catch (Exception ex)
{

Without the correction the ManifestParser contructor call throws an exception complaining that an exported capability cannot be blank. That extra comma in the syspkgs made the parser think that some capability was missing.

And once you fail in that try block you don't get your host osgi.ee capabilities added to your framework which means you can't resolve requests like (&(osgi.ee=JavaSE)(version=1.8))

Just to be clear, this is the specific version I am referring to:

org.apache.felix:org.apache.felix.framework:5.6.10

This issue only occurs if you add some extra system capabilities to your configuration like I did. So that might explain why some people see this problem and others don't.

I've applied the patch and the filers are once again working.

score 1 · Answer 6 · answered Jul 12 '18 at 16:52

1

Real and Quick Solution:

"I edited the Plug-ins tab on the Run Configuration and checked org.eclipse.equinox.ds and clicked 'Add Required Plug-ins'. THAT FIXED IT."

https://bugs.eclipse.org/bugs/show_bug.cgi?id=494913#c2

answered Jul 12 '18 at 16:52

Alejandro Hdz

143
4

That did it for me. – Ayman Salah Oct 02 '18 at 11:16

score 0 · Answer 7 · answered Apr 19 '17 at 11:34

0

I got this error in liferay dxp. I had changed liferay workspace and it is working fine.

answered Apr 19 '17 at 11:34

Tushar Patel

573
3
17

score 0 · Answer 8 · answered Feb 08 '18 at 03:09

I have the same issue: Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))

I am using Felix 5.6.10

Here's an interesting thing I discovered: I created two test.jar bundles that contain the following MANIFEST.MF

test1.jar Manifest-Version: 1.0 Bundle-Description: bundle used for testing Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee=JavaSE; version="1.8" Created-By: 1.8.0_131 (Oracle Corporation)

test2.jar: Manifest-Version: 1.0 Bundle-Description: bundle used for testing Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.2 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version 1.8))" Created-By: 1.8.0_131 (Oracle Corporation)

As you can see the two bundles only differ in the Bundle-Version and how the required capability is specified.

The result is: test1.jar installs just fine test2.jar produces the missing requirement message when you try to install it.

So there's something about using a filter in the Require-Capability header that doesn't work in my felix osgi framework. Is it not supported, is there something I need to configure to enable filters? It's clearly not because my framework isn't configured for having the required osgi.ee capability (test1.jar works).

Obviously, that means if I correct the Require-Capability header in the faulting bundles, I got a workaround. (Not a good solution if you're installing your bundles from an open repository.)