web-dev-qa-db-fra.com

Java 8 & Capacité requise manquante Require-Capability: osgi.ee; filter = "(& (osgi.ee = JavaSE) (version = 1.8))"

J'ai utilisé Eclipse Luna win32.x86_64 sous Java 8.

Voici du Help Menu > About > Installation Detail > Configuration Tab:

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

J'ai créé un nouveau projet de plug-in, demandant JavaSE-1.8 en tant qu'environnement d'exécution:

Plug-in Editor. JavaSE-1.8 as Execution Environment

Dans le fichier myplugin/META-INF/MANIFEST.MF j'ai bien sûr:

 Bundle-RequiredExecutionEnvironment: JavaSE-1.8

J'utilise ce plugin dans un fichier produit. Lorsque j'essaie de le valider, j'obtiens l'erreur suivante:

Validations Dialog, opened from the product file editor

Bien sûr, si je lance le produit, je reçois:

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

J'ai essayé de vérifier beaucoup:

Préférences> Java> JRE installés

Installed JREs

Préférences> Java> JRE installés> Environnements d’excution

Excution Environments

Préférences> Java> Compilateur: Conformité JDK Niveau de conformité du compilateur

Compiler

Lorsque je démarre le produit, j'ai vérifié dans l'onglet Launching que j'utilisais jre8 comme environnement d'exécution.

J'ai même essayé de changer le Java Runtime Environment dans la boîte de dialogue Run Configurations:

Java Runtime Environment

J'ai essayé différents réglages. Aucun d'entre eux ne fonctionne.

Qu'est-ce qui ne va pas?

Est-ce un problème connu?

eclipseeclipse-pluginosgijava-8equinox
30
Jmini

L'erreur signifie que votre paquet a une entrée Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" dans son manifeste. Cela signifie donc que le bundle ne démarrera que s’il existe un bundle offrant cette possibilité.

Dans le cas de la capacité osgi.ee, c'est le cadre OSGi (équinoxe) qui devrait fournir cette capacité. Apparemment, cela ne se fait pas.

Ainsi, une approche consisterait à supprimer l’en-tête de votre fichier d’ensemble Manifest . L’autre solution consisterait à faire en sorte que la capacité soit exportée par équinoxe. Peut-être pourriez-vous simplement essayer avec la dernière version de l'équinoxe. Vous ne savez pas trop si cela vous aidera. Vous pouvez également essayer de définir la propriété d'infrastructure (à l'aide de -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"

Voir

18
Christian Schneider

Partage de mon expérience sur la mise à niveau d'une plateforme cible basée sur Juno 3.8.2 pour exécuter des tests de plug-in JUnit avec Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8:

Echec de l'approche 1: fragment

Création d'un fragment sur org.Eclipse.osgi avec un en-tête Provide-Capability dans le manifeste:

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"

Cette capacité n'a jamais été captée.

Echec de l'approche 2: paramètre de démarrage

Utiliser -Dorg.osgi.framework.system.capabilities comme indiqué dans la réponse de Christian.

Tout d'abord, l'argument doit être cité correctement:

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

Cette approche pourrait avoir fonctionné pour tout autre cas d'utilisation autre que pde.junit. J'ai toujours cette exception (légèrement différente):

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

Approche de travail 3: Patch Equinox

Corrigez le paquet org.Eclipse.osgi pour inclure le JavaSE-1.8.profile de Luna. 

  1. Copiez le fichier <LUNA>\plugins\org.Eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile dans le bundle org.Eclipse.osgi de votre pool de bundles de la plateforme cible.
    (par exemple <myworkspace>\.metadata\.plugins\org.Eclipse.pde.core\.bundle_pool\plugins\org.Eclipse.osgi_3.8.2.v20130124-134944.jar\JavaSE-1.8.profile)

  2. Profil de référence dans profile.list (en fait, cela semble être facultatif):
    ajouter JavaSE-1.8.profile,\ à .metadata\.plugins\org.Eclipse.pde.core\.bundle_pool\plugins\org.Eclipse.osgi_3.8.2.v20130124-134944.jar\profile.list

Cependant, cette solution nécessite l'hébergement de votre propre référentiel P2 contenant l'ensemble org.Eclipse.osgi ou l'application d'un correctif au pool d'ensembles de chaque espace de travail.

Discussion

Néanmoins, il existe la possibilité de conserver BREE sur "JavaSE-1.7" compatible avec la version org.Eclipse.osgi 3.8.2 existante. 

Je suis actuellement conscient de deux inconvénients:

  • L'exportation de plug-ins directement à partir d'Eclipse via PDE échoue si la syntaxe Java 8 est utilisée dans le code (par exemple, des expressions lambda). 
  • Le journal contient des erreurs de compilation et le résultat compilé est en réalité de taille différente de celle d'un ensemble compilé avec JavaSE-1.8 BREE.

PDE évalue vraisemblablement BREE et définit le niveau source du compilateur en conséquence, ce qui donne ensuite "1,7" pour les sources Java 8. Il est possible que d'autres fonctionnalités PDE (exportation de fonctionnalités, exportation de produits) présentent le même problème.

À l’aide de Eclipse Tycho , il est possible de remplacer manuellement le niveau source de javac au lieu d’évaluer BREE d’un ensemble (pour sélectionner un JDK avec lequel compiler). Cependant, Tycho correspond toujours au niveau source indiqué par rapport à BREE et refuse de compiler le code Java 8 (testé avec Tycho 0.22). 

En outre, l'approche 2 ne fonctionnera probablement pas avec l'exportation par lots de PDE. Du moins, je ne suis au courant d'aucune possibilité de passer des arguments VM.

Mise à jour 29.05.2015

Nous avons opté pour l’approche 3 et avons corrigé avec succès notre plate-forme cible afin d’utiliser Java 8 avec Eclipse 3.8. 

Comme nous gérons déjà notre propre référentiel P2 avec tous les plugins Eclipse basés sur la version 3.8, nous devions:

  • créer une copie mise à jour de org.Eclipse.osgi (nécessaire pour supprimer également les informations de signature de l'ensemble)
  • créer un patch de fonctionnalité qui corrige la fonctionnalité org.Eclipse.rcp avec le paquet org.Eclipse.osgi mis à jour
  • publier un nouveau référentiel P2 basé sur 3.8 à utiliser par nos stations de travail et construire un serveur.

Résumé

Si vous conservez votre propre référentiel P2 pour desservir une plate-forme cible personnalisée au lieu d'utiliser un site de mise à jour basé sur Eclipse.org, il est possible de faire fonctionner Eclipse 3.8 avec Java 8.

Références: Eclipse Bug to support osgi.ee

16
Henrik Steudel

J'ai trouvé une configuration qui fonctionne, sans trop de travail. Vous sélectionnez Java 8 dans le fichier du produit, les paramètres du projet et le chemin de génération. L'important est le fichier manifeste. Ici, vous devez sélectionner Java 8 et Java 7. Ici aussi, l'ordre est important. Java 8 doit être au top.

Je pense que la raison pour laquelle cette configuration fonctionne est que le compilateur sélectionne le premier JRE et peut donc gérer la nouvelle syntaxe de Java 8. Les bundles Eclipse vérifient si l’une des entrées est Java 7 nécessaire et est également satisfaite.

3
stefan

Une solution facile consiste à inclure org.Eclipse.equinox.ds (services déclaratifs d'équinoxe). Cet ensemble d'exécution exporte le fichier osgi.extender requis et ne semble déclencher aucune dépendance supplémentaire.

3
andrew glynn

J'ai le même problème: Capacité requise manquante Require-Capability: osgi.ee; filter = "(& (osgi.ee = JavaSE) (version = 1.8))

J'utilise Felix 5.6.10 

Voici une chose intéressante que j'ai découverte: J'ai créé deux ensembles de test.jar contenant le fichier MANIFEST.MF suivant.

test1.jar Manifest-Version: 1.0 Bundle-Description: bundle utilisé pour tester Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name : testbundle Bundle-ManifestVersion: 2 Capacité requise: osgi.ee = JavaSE; version = "1.8" Créé par: 1.8.0_131 (Oracle Corporation)

test2.jar: Manifest-Version: 1.0 Bundle-Description: bundle utilisé pour tester Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.2 Bundle- Nom: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee; filter: = "(& (osgi.ee = JavaSE) (version 1.8))" Créé-Par: 1.8. 0_131 (Oracle Corporation)

Comme vous pouvez le constater, les deux offres ne diffèrent que par leur version et la manière dont la capacité requise est spécifiée. 

Le résultat est le suivant: Test1.jar installe correctement Test2.jar génère le message de condition manquante lorsque vous essayez de l'installer.

Il y a donc quelque chose à propos de l'utilisation d'un filtre dans l'en-tête Require-Capability qui ne fonctionne pas dans mon framework felix osgi. N'est-il pas pris en charge, dois-je configurer quelque chose pour activer les filtres? Ce n'est clairement pas parce que mon framework n'est pas configuré pour avoir la capacité requise osgi.ee (test1.jar fonctionne).

Évidemment, cela signifie que si je corrige l'en-tête Require-Capability dans les ensembles défaillants, j'ai une solution de contournement. (Ce n'est pas une bonne solution si vous installez vos bundles à partir d'un référentiel ouvert.)

0
tom

J'ai eu cette erreur dans la vie dxp. J'avais changé de poste de travail à vie et tout fonctionnait bien.

0
Tushar Patel

J'ai trouvé le problème dans la version de Felix 5.6.10 qui était à l'origine de mon problème:

"Capacité requise manquante Capacité requise: osgi.ee; filter =" (& (osgi.ee = JavaSE) (version = 1.8)) "

C'est le code qui crée le problème . C'est dans le constructeur de 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);

a changé la dernière ligne en:

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

la raison pour laquelle cela pose un problème est qu’un peu plus loin dans le constructeur nous trouvons ce 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)
{

Sans la correction, l'appel du constructeur de ManifestParser lève une exception en se plaignant du fait qu'une capacité exportée ne peut pas être vide. Cette virgule supplémentaire dans les syspkgs a amené l’analyseur à penser qu’il manquait une capacité. 

Et une fois que vous échouez dans ce bloc d’essai, vos capacités d’hôte osgi.ee ne sont pas ajoutées à votre infrastructure, ce qui signifie que vous ne pouvez pas résoudre les requêtes telles que (& (osgi.ee = JavaSE) (version = 1.8))

Pour être clair, voici la version spécifique à laquelle je me réfère:

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

Ce problème ne se produit que si vous ajoutez des fonctionnalités système supplémentaires à votre configuration, comme je l'ai fait. Cela pourrait donc expliquer pourquoi certaines personnes voient ce problème et d’autres pas.

J'ai appliqué le correctif et les serveurs de fichiers fonctionnent à nouveau.

0
tom