it-swarm.com.de

Java 8 & Fehlende erforderliche Fähigkeit Erforderliche Fähigkeit: osgi.ee; filter = "(& (osgi.ee = JavaSE) (Version = 1.8))"

Ich habe Eclipse Luna win32.x86_64 mit Java 8 ausgeführt.

Hier aus dem Help Menu > About > Installation Detail > Configuration Tab:

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

Ich habe ein neues Plug-In-Projekt erstellt und forderte JavaSE-1.8 als Ausführungsumgebung an:

Plug-in Editor. JavaSE-1.8 as Execution Environment

In der myplugin/META-INF/MANIFEST.MF-Datei habe ich natürlich:

 Bundle-RequiredExecutionEnvironment: JavaSE-1.8

Ich verwende dieses Plugin in einer Produktdatei. Wenn ich versuche, es zu überprüfen, erhalte ich folgende Fehlermeldung:

Validations Dialog, opened from the product file editor

Wenn ich das Produkt starte, bekomme ich natürlich:

!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 [email protected]********/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))".

Ich habe viel versucht zu überprüfen:

Einstellungen> Java> Installierte JREs

Installed JREs

Einstellungen> Java> Installierte JREs> Excution Environments

Excution Environments

Einstellungen> Java> Compiler: Kompatibilitätsstufe für JDK Compliance Compiler

Compiler

Beim Starten des Produkts habe ich auf der Registerkarte Launching überprüft, dass ich die jre8 als Ausführungsumgebung verwende.

Ich habe sogar versucht, den Java Runtime Environment im Run Configurations-Dialog zu ändern:

Java Runtime Environment

Ich habe verschiedene Einstellungen ausprobiert. Keiner von ihnen funktioniert.


Was ist falsch?

Ist es ein bekanntes Problem?

30
Jmini

Der Fehler bedeutet, dass Ihr Bundle einen Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))"-Eintrag in seinem Manifest hat. Das bedeutet, dass das Bundle nur gestartet wird, wenn ein Bundle vorhanden ist, das diese Funktion bietet.

Im Falle der osgi.ee-Funktion sollte das OSGi-Framework (Equinox) diese Funktion bereitstellen. Anscheinend tut es das nicht.

Ein Ansatz wäre also, den Header aus Ihrem Manifest-Bündel zu entfernen ..__ Der andere wäre, Equinox die Funktion exportieren zu lassen. Vielleicht könnten Sie es einfach mit der neuesten Äquinoktikaversion versuchen. Nicht sicher, ob dies hilft. Sie können auch versuchen, die Framework-Eigenschaft festzulegen (mithilfe von -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"

Sehen

18

Weitergabe meiner Erfahrungen beim Nachrüsten einer Zielplattform auf Basis von Juno 3.8.2 zum Ausführen von JUnit-Plug-Ins mit Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8:

Fehlgeschlagener Ansatz 1: Fragment

Erstellen eines Fragments für org.Eclipse.osgi mit einem Provide-Capability-Header im 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"

Diese Fähigkeit wurde nie aufgegriffen.

Fehlgeschlagener Ansatz 2: Startparameter

Verwenden Sie -Dorg.osgi.framework.system.capabilities wie in Christians Antwort beschrieben.

Zunächst muss das Argument korrekt zitiert werden:

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

Dieser Ansatz hat möglicherweise für alle anderen Anwendungsfälle als pde.junit funktioniert. Ich habe immer noch diese (etwas andere) Ausnahme:

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

Arbeitsansatz 3: Patch Equinox

Patchen Sie das org.Eclipse.osgi-Bundle, um Luna JavaSE-1.8.profile einzuschließen. 

  1. Kopieren Sie die Datei <LUNA>\plugins\org.Eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile in das Paket org.Eclipse.osgi des Zielplattform-Pools.
    (z. B. <myworkspace>\.metadata\.plugins\org.Eclipse.pde.core\.bundle_pool\plugins\org.Eclipse.osgi_3.8.2.v20130124-134944.jar\JavaSE-1.8.profile)

  2. Referenzprofil in profile.list (dies scheint tatsächlich optional zu sein):
    JavaSE-1.8.profile,\ zu .metadata\.plugins\org.Eclipse.pde.core\.bundle_pool\plugins\org.Eclipse.osgi_3.8.2.v20130124-134944.jar\profile.list hinzufügen

Für diese Lösung müssen Sie jedoch Ihr eigenes P2-Repository mit dem org.Eclipse.osgi-Bundle hosten oder einen Patch auf den Bundle-Pool jedes Arbeitsbereichs anwenden.

Diskussion

Dennoch besteht die Möglichkeit, BREE auf "JavaSE-1.7" zu belassen, das mit der vorhandenen Version org.Eclipse.osgi 3.8.2 kompatibel ist. 

Mir sind momentan zwei Nachteile bekannt:

  • Der Export von Plugins direkt aus Eclipse über PDE schlägt fehl, wenn im Code Java 8-Syntax verwendet wird (z. B. Lambda-Ausdrücke). 
  • Das Protokoll enthält Compiler-Fehler und das kompilierte Ergebnis ist tatsächlich von anderer Größe als ein mit JavaSE-1.8 BREE kompiliertes Bundle.

Vermutlich wertet PDE BREE aus und stellt die Compiler-Quellebene entsprechend ein, was für Java 8-Quellen "1,7" ergibt. Es ist möglich, dass andere PDE-Funktionen (Funktionsexport, Produktexport) dasselbe Problem aufweisen.

Mit Eclipse Tycho ist es möglich, den Javac-Quellpegel manuell zu überschreiben, anstatt den BREE eines Bundles auszuwerten (um ein JDK zum Kompilieren auszuwählen). Tycho stimmt jedoch auch weiterhin mit dem angegebenen Quellpegel vs. BREE überein und lehnt die Kompilierung von Java 8-Code ab (getestet mit Tycho 0.22). 

Außerdem funktioniert Ansatz 2 höchstwahrscheinlich nicht mit dem PDE-Export von Bundle. Zumindest sind mir keine Möglichkeiten bekannt, VM - Argumente zu übergeben.

Update vom 29.05.2015

Wir haben uns für Ansatz 3 entschieden und unsere Zielplattform erfolgreich gepatcht, um Java 8 zusammen mit Eclipse 3.8 zu verwenden. 

Da wir bereits ein eigenes P2-Repository mit allen 3.8-basierten Eclipse-Plugins verwalten, mussten wir:

  • erstellen Sie eine aktualisierte Kopie von org.Eclipse.osgi (erforderlich, um auch die Signaturinformationen aus dem Bundle zu entfernen).
  • erstellen Sie ein Feature-Patch, das die org.Eclipse.rcp-Funktion mit dem aktualisierten org.Eclipse.osgi-Paket aktualisiert
  • veröffentlichen Sie ein neues 3.8-basiertes P2-Repository, das von unseren Workstations und Build-Servern verwendet werden kann.

Zusammenfassung

Wenn Sie ein eigenes P2-Repository verwalten, um eine benutzerdefinierte Zielplattform bereitzustellen, anstatt eine Eclipse.org-basierte Aktualisierungssite zu verwenden, können Sie Eclipse 3.8 mit Java 8 unterstützen.

Referenzen: Eclipse Bug zur Unterstützung von osgi.ee

16
Henrik Steudel

Ich habe eine Konfiguration gefunden, die einfach funktioniert, ohne viel Arbeit. Sie wählen Java 8 in der Produktdatei, in den Projekteinstellungen und im Erstellungspfad. Das Wichtigste ist die Manifestdatei. Hier müssen Sie sowohl Java 8 als auch Java 7 auswählen. Auch hier ist die Reihenfolge wichtig. Java 8 muss oben sein.

Ich denke, der Grund, warum diese Konfiguration funktioniert, ist, dass der Compiler die erste JRE auswählt und somit die neue Syntax von Java 8 verarbeiten kann. Die Eclipse-Bundles prüfen, ob einer der Einträge der benötigte Java 7-Server ist und auch erfüllt ist.

3
stefan

Eine einfache Lösung besteht darin, org.Eclipse.equinox.ds (deklarative Dienste für Equinox) einzuschließen. Dieses Laufzeitpaket exportiert den erforderlichen osgi.extender und scheint keine zusätzlichen Abhängigkeiten auszulösen.

3
andrew glynn

Reale und schnelle Lösung:

" Ich habe die Registerkarte" Plug-Ins "in der Ausführungskonfiguration bearbeitet und" org.Eclipse.equinox.ds "markiert und auf" Erforderliche Plug-Ins hinzufügen "geklickt. DAS BEHEBTE ES . "

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

1
Alejandro Hdz

Ich habe das gleiche Problem: Fehlende erforderliche Fähigkeit Require-Capability: osgi.ee; filter = "(& (osgi.ee = JavaSE) (Version = 1.8))

Ich benutze Felix 5.6.10 

Hier ist eine interessante Sache, die ich entdeckt habe: Ich habe zwei test.jar-Bundles erstellt, die die folgenden MANIFEST.MF-Dateien enthalten

test1.jar Manifest-Version: 1.0 Bundle-Beschreibung: Zum Testen verwendetes Bundle Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name : testbundle Bundle-ManifestVersion: 2 Erforderliche Fähigkeit: osgi.ee = JavaSE; version = "1.8" Erstellt von: 1.8.0_131 (Oracle Corporation)

test2.jar: Manifest-Version: 1.0 Bundle-Beschreibung: Zum Testen verwendetes Bundle Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.2 Bundle- Name: testbundle Bundle-ManifestVersion: 2 Erforderliche Fähigkeit: osgi.ee; filter: = "(& (osgi.ee = JavaSE) (Version 1.8))" Erstellt von: 1.8. 0_131 (Oracle Corporation)

Wie Sie sehen, unterscheiden sich die beiden Bundles nur in der Bundle-Version und wie die erforderliche Fähigkeit festgelegt ist. 

Das Ergebnis ist: Test1.jar installiert sich gut Test2.jar erzeugt die fehlende Anforderung, wenn Sie versuchen, es zu installieren.

Es gibt also etwas über die Verwendung eines Filters im Require-Capability-Header, der in meinem felix osgi-Framework nicht funktioniert. Wird es nicht unterstützt? Muss ich etwas konfigurieren, um Filter zu aktivieren? Das liegt natürlich nicht daran, dass mein Framework nicht für die erforderliche osgi.ee-Fähigkeit konfiguriert ist (test1.jar funktioniert).

Das heißt natürlich, wenn ich den Require-Capability-Header in den fehlerhaften Paketen korrigiere, habe ich eine Problemumgehung erhalten. (Keine gute Lösung, wenn Sie Ihre Bundles aus einem offenen Repository installieren.)

0
tom

Ich habe diesen Fehler in Liferay DXP bekommen. Ich hatte den Liferay-Arbeitsbereich geändert und es funktioniert gut.

0
Tushar Patel

Ich habe das Problem in der Version Felix 5.6.10 gefunden, die mein Problem verursacht hat:

"Fehlende erforderliche Fähigkeit Require-Capability: osgi.ee; filter =" (& (osgi.ee = JavaSE) (version = 1.8)) "

Dies ist der Code, mit dem das Problem erstellt wird . Es befindet sich im Konstruktor des ExtensionManagers

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

änderte die letzte Zeile in:

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

der Grund für das Problem ist, dass wir etwas weiter im Konstruktor diesen Code finden:

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

Ohne die Korrektur löst der ManifestParser-Konstruktoraufruf eine Ausnahme aus, die besorgt, dass eine exportierte Funktion nicht leer sein darf. Dieses zusätzliche Komma in den syspkgs ließ den Parser vermuten, dass einige Fähigkeiten fehlten. 

Und wenn Sie in diesem try-Block nicht erfolgreich sind, werden Ihre Host osgi.ee-Funktionen nicht zu Ihrem Framework hinzugefügt. Dies bedeutet, dass Sie keine Anfragen wie (& (osgi.ee = JavaSE) (version = 1.8)) lösen können.

Nur um klar zu sein, das ist die spezifische Version, auf die ich mich beziehe:

org.Apache.felix:org.Apache.felix.framework:5.6.10

Dieses Problem tritt nur auf, wenn Sie Ihrer Konfiguration einige zusätzliche Systemfunktionen hinzufügen wie ich. Das könnte erklären, warum manche Leute dieses Problem sehen und andere nicht.

Ich habe den Patch angewendet und die Filer funktionieren wieder.

0
tom