问Java 8&缺少所需的能力需求-功能: osgi.ee；filter="(&(osgi.ee=JavaSE)(version=1.8))“

EN

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

对于osgi.ee功能，应该是OSGi框架(春分)提供这种功能。显然它做不到这一点。

因此，一种方法是从bundle Manifest中删除标头。另一种是使春分出口能力。也许你可以试一下最新的春分版本。但不确定这是否有帮助。您还可以尝试设置框架属性(使用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“)：-D

看见

• eclipse列表中的相同问题

分享我在基于Juno3.8.2对目标平台进行改造以使用JavaSE-1.8 ("BREE")运行JUnit插件测试方面的经验

失败的方法1:片段

使用清单中的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"

这种能力从来没有得到过。

失败的方法2:启动参数

使用-Dorg.osgi.framework.system.capabilities，如克里斯蒂安的答案所述。

首先，必须正确引用这一论点：

-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\""

这种方法可能适用于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)

工作方法3:片均分

修补org.eclipse.osgi包，包括露娜的JavaSE-1.8.profile。

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

但是，这个解决方案需要承载包含P2包的自己的org.eclipse.osgi存储库，或者将补丁应用到每个工作区的包池中。

讨论

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

我目前知道有两个缺点：

• 如果代码中使用Java 8语法(例如lambda表达式)，则通过PDE直接从Eclipse导出插件失败。
• 日志包含编译器错误，与使用JavaSE-1.8BREE编译的包相比，编译结果实际上是不同的。

据推测，PDE评估BREE并相应地设置编译器源代码级别，从而为Java 8源代码生成"1.7“。其他PDE特性(功能导出、产品导出)可能也会出现同样的问题。

使用月食台谷，可以手动覆盖javac源代码级别，而不是计算包的BREE (选择要编译的JDK )。但是，Tycho仍然匹配给定的源代码级别与BREE，并且拒绝编译Java 8代码(使用Tycho 0.22进行测试)。

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

更新29.05.2015

我们采用了方法3，并成功地修补了我们的目标平台，使其与Eclipse3.8一起使用Java 8。

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

• 创建org.eclipse.osgi的更新副本(也需要从包中删除签名信息)
• 创建一个功能修补程序，用更新的org.eclipse.rcp包对org.eclipse.osgi特性进行修补
• 发布新的基于3.8的P2存储库，供我们的工作站和构建服务器使用.

摘要

如果您维护自己的P2存储库以服务自定义目标平台，而不是使用任何基于Eclipse.org的更新站点，则可以使Eclipse3.8与Java8协同工作。

参考资料：Eclipse支持osgi.ee

一个简单的解决方法是包含org.eclipse.equinox.ds (春分声明性服务)。运行时包导出所需的osgi.extender，并且似乎不触发任何附加的依赖项。