eclipse Java 8 & 缺少所需的能力 Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"

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

提问by Jmini

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

我使用 Eclipse Luna win32.x86_64 运行 Java 8。

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

这里来自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.8as Execution Environment:

我创建了新的插件项目，请求JavaSE-1.8作为执行环境：

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

在myplugin/META-INF/MANIFEST.MF我当然有的文件中：

 Bundle-RequiredExecutionEnvironment: JavaSE-1.8

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

我在产品文件中使用这个插件。当我尝试验证它时，出现以下错误：

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

首选项 > Java > 已安装的 JRE

Preferences > Java > Installed JREs > Excution Environments

首选项 > Java > 已安装的 JRE > 执行环境

Preferences > Java > Compiler: JDK Compliance Compiler compliance level

首选项 > Java > 编译器：JDK 合规编译器合规级别

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

当我启动产品时，我在Launching选项卡中检查了我使用 jre8 作为执行环境。

I have even tried to change the Java Runtime Environmentin the Run ConfigurationsDialog:

我甚至试图改变Java Runtime Environment在Run Configurations对话框：

I have tried different settings. None of them works.

我尝试了不同的设置。它们都不起作用。

---

---

What is wrong?

怎么了？

Is it a known issue?

这是一个已知问题吗？

采纳答案by Christian Schneider

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.

该错误意味着您的包Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"在其清单中有一个条目。因此，这意味着仅当有提供此功能的捆绑包时，捆绑包才会启动。

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

对于 osgi.ee 功能，OSGi 框架 (equinox) 应该提供此功能。显然它不会这样做。

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"

因此，一种方法是从捆绑清单中删除标头。另一种是使春分输出能力。也许您可以简单地尝试使用最新的 equinox 版本。不确定这是否有帮助。您也可以尝试设置框架属性（使用 -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

• eclipse列表上同样的问题

回答by Henrik Steudel

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:

分享我改造基于 Juno 3.8.2 的目标平台以使用Bundle-RequiredExecutionEnvironment("BREE")运行 JUnit 插件测试的经验JavaSE-1.8：

Failed approach 1: Fragment

失败的方法一：Fragment

Creating a fragment to org.eclipse.osgiwith a Provide-Capabilityheader in the manifest:

org.eclipse.osgi使用Provide-Capability清单中的标头创建片段：

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

失败的方法2：启动参数

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

-Dorg.osgi.framework.system.capabilities按照 Christian 的回答中的概述使用。

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:

这种方法可能适用于除pde.junit. 我仍然有这个（略有不同）异常：

!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

工作方法 3：补丁 Equinox

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

修补org.eclipse.osgi捆绑包以包含 Luna 的JavaSE-1.8.profile.

1. Copy file <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profileto your target platform bundle pool's org.eclipse.osgibundle.
   (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)

2. 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

1. 将文件复制<LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile到目标平台包池的org.eclipse.osgi包。
   （例如<myworkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.osgi_3.8.2.v20130124-134944.jar\JavaSE-1.8.profile）

2. 参考资料profile.list（实际上，这似乎是可选的）：
   添加JavaSE-1.8.profile,\到 .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.osgibundle or applying a patch to every workspace's bundle pool.

但是，此解决方案需要托管您自己的包含org.eclipse.osgi包的 P2 存储库或将补丁应用于每个工作区的包池。

Discussion

讨论

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

尽管如此，仍有可能将 BREE 保持在与现有org.eclipse.osgi3.8.2 版本兼容的“JavaSE-1.7” 。

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.

• 如果代码中使用了 Java 8 语法（例如 lambda 表达式），则通过 PDE 从 Eclipse 直接导出插件会失败。
• 日志包含编译器错误，与使用 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.

据推测，PDE 会评估 BREE 并相应地设置编译器源代码级别，然后为 Java 8 源代码生成“1.7”。其他 PDE 功能（功能导出、产品导出）可能会出现相同的问题。

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).

使用Eclipse Tycho，可以手动覆盖 javac 源代码级别而不是评估包的 BREE（选择要编译的 JDK）。然而，第谷仍然匹配给定的源代码级别与 BREE 并拒绝编译 Java 8 代码（用第谷 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.

此外，方法 2 很可能不适用于 PDE 的包导出，至少我不知道有任何可能传递 VM 参数。

Update 29.05.2015

2015 年 5 月 29 日更新

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

我们采用了方法 3，并成功地修补了我们的目标平台，以便将 Java 8 与 Eclipse 3.8 一起使用。

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

由于我们已经使用所有基于 3.8 的 Eclipse 插件维护了我们自己的 P2 存储库，因此我们需要：

• 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.rcpfeature with updated org.eclipse.osgibundle
• publish new 3.8-based P2 repository to be consumed by our workstations and build server.

• 创建一个更新的副本org.eclipse.osgi（还需要从包中删除签名信息）
• 创建一个功能补丁，org.eclipse.rcp用更新的org.eclipse.osgi包修补功能
• 发布新的基于 3.8 的 P2 存储库，供我们的工作站和构建服务器使用。

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.

如果您维护自己的 P2 存储库来为自定义目标平台提供服务，而不是使用任何基于 Eclipse.org 的更新站点，则可以使 Eclipse 3.8 与 Java 8 一起工作。

References: Eclipse Bug to support osgi.ee

参考：Eclipse Bug 支持 osgi.ee

回答by Stefan

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.

我找到了一个可以正常工作的配置，无需太多工作。您在产品文件、项目设置和构建路径中选择 Java 8。重要的是清单文件。在这里，您必须同时选择 Java 8 和 Java 7。这里的顺序也很重要。Java 8 必须处于领先地位。

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.

我认为这种配置有效的原因是编译器选择了第一个 JRE，因此可以处理 Java 8 的新语法。 eclipse 包检查其中一个条目是否是所需的 Java 7 并且也满足。

回答by andrew glynn

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.

一个简单的解决方法是包含 org.eclipse.equinox.ds（equinox 声明性服务）。该运行时包导出所需的 osgi.extender 并且似乎不会触发其他依赖项。

回答by Alejandro Hdz

Real and Quick Solution:

真实快速的解决方案：

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

“我编辑了运行配置上的插件选项卡并检查了org.eclipse.equinox.ds并单击了“添加所需的插件”。修复了它。“

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

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

回答by Tushar Patel

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

我在liferay dxp 中遇到了这个错误。我已经改变了 Liferay 工作区，它工作正常。

回答by tom

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

我有同样的问题：缺少所需的能力 Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))

I am using Felix 5.6.10

我正在使用 Felix 5.6.10

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

这是我发现的一件有趣的事情：我创建了两个 test.jar 包，其中包含以下 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)

test1.jar Manifest-Version: 1.0 Bundle-Description: 用于测试的bundle 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)

test2.jar: Manifest-Version: 1.0 Bundle-Description: 用于测试的bundle 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))" 创建者：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.

如您所见，这两个包仅在 Bundle-Version 和所需功能的指定方式上有所不同。

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

结果是： test1.jar 安装得很好 test2.jar 在您尝试安装时会产生缺少的需求消息。

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).

因此，在我的 felix osgi 框架中无法使用 Require-Capability 标头中的过滤器。是否不支持，是否需要配置某些内容才能启用过滤器？这显然不是因为我的框架没有配置为具有所需的 osgi.ee 功能（test1.jar 有效）。

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.)

显然，这意味着如果我更正错误包中的 Require-Capability 标头，我就有了解决方法。（如果您从开放存储库安装包，这不是一个好的解决方案。）

回答by tom

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

我在 Felix 5.6.10 版本中发现了导致我的问题的问题：

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

“缺少所需的能力 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

这是产生问题的代码。它在 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.

如果没有更正， ManifestParser 构造函数调用会引发异常，抱怨导出的功能不能为空。syspkgs 中的额外逗号使解析器认为缺少某些功能。

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))

一旦你在那个 try 块中失败了，你就不会将你的主机 osgi.ee 功能添加到你的框架中，这意味着你无法解决像 (&(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.

我已经应用了补丁，文件管理器再次工作。