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

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

échec de l'approche 1: Fragment

Création d'un fragment d' org.eclipse.osgi avec un Provide-Capability en-tête dans le 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"

cette capacité n'a jamais été détectée.

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

en utilisant -Dorg.osgi.framework.system.capabilities tel que décrit dans réponse.

tout d'Abord, l'argument doit être indiqué 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 (légèrement différente) 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)

approche de travail 3: Patch Equinox

Patch org.eclipse.osgi bundle pour inclure de Luna JavaSE-1.8.profile.

1. Copier le fichier <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile pour votre plate-forme cible bundle de la piscine org.eclipse.osgi bundle.
   
   (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 dépôt P2 contenant le org.eclipse.osgi regrouper ou appliquer un patch à chaque groupe de paquets de l'espace de travail.

Discussion

pourtant, il existe la possibilité de garder BREE à " JavaSE-1.7" qui est compatible avec l'existant org.eclipse.osgi 3.8.2 version.

je suis actuellement conscients de deux inconvénients:

• exporter des plugins directement à partir D'Eclipse via PDE échoue si la syntaxe Java 8 est utilisée dans le code (par exemple les expressions lambda).
• Log contient des erreurs de compilation et le résultat compilé est en fait de taille différente par rapport à un paquet compilé avec JavaSE-1.8 BREE.

vraisemblablement, PDE évalue BREE et définit la source du compilateur niveau en conséquence qui aboutit à " 1.7 " Pour les sources Java 8. Il est possible que d'autres caractéristiques de L'ECE (exportation de caractéristiques, exportation de produits) présentent le même problème.

en utilisant Eclipse Tycho, il est possible de modifier manuellement le niveau Source javac au lieu d'évaluer la BREE d'un paquet (pour sélectionner un JDK à compiler). Cependant, Tycho correspond toujours au niveau source donné vs. BREE et refuse de compiler le code Java 8 (testé avec Tycho 0.22).

de plus, l'approche 2 ne fonctionnera probablement pas avec le bundle export de PDE, du moins je ne suis pas au courant d'une possibilité de passer les arguments VM.

mise à Jour 29.05.2015

nous avons adopté l'approche 3 et corrigé avec succès notre plate-forme cible pour utiliser Java 8 avec Eclipse 3.8.

comme nous maintenons déjà notre propre dépôt P2 avec tous les plugins 3.8-basés Eclipse, nous avions besoin de:

• créer une copie mise à jour de org.eclipse.osgi (nécessaires à la bande de signature d'informations à partir de bundle)
• créer un patch correctifs org.eclipse.rcp fonctionnalité avec mise à jour org.eclipse.osgi bundle
• publier un nouveau dépôt P2 3.8 basé sur nos stations de travail et notre serveur de construction.

Sommaire

si vous maintenez votre propre dépôt P2 pour servir une plate-forme cible personnalisée au lieu d'utiliser N'importe quelle Eclipse.site de mise à jour basé sur l'organisation, il est possible de faire fonctionner Eclipse 3.8 avec Java 8.

Références: bogue Eclipse pour supporter osgi.ee

j'ai trouvé une configuration qui fonctionne sans trop de travail. Vous sélectionnez Java 8 dans le fichier produit, les paramètres du projet et le chemin de construction. L'important, c'est le fichier manifeste. Ici, vous devez sélectionner à la fois Java 8 et Java 7. Ici aussi l'ordre est important. Java 8 doit être au-dessus.

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. L'éclipse faisceaux de vérifier si l'une des entrées est la nécessaire Java 7 et sont également satisfaits.

Une solution facile est d'inclure org.Eclipse.équinoxe.ds (équinoxe déclarative des services). Ce pack d'exécution exporte l'osgi nécessaire.extender et semble déclencher aucune dépendance supplémentaire.

Solution réelle et rapide:

"j'ai édité l'onglet Plugins sur la Configuration d'Exécution et vérifié!--4 -- > org.Eclipse.équinoxe.ds et cliquez sur "Ajouter les Plug-ins requis". THAT FIXED IT."

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

j'ai eu cette erreur dans liferay dxp. J'avais changé l'espace de travail de liferay et il fonctionne très bien.

j'ai le même problème: le Manque de capacité de Besoin-Capacité: 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 test.paquets de pots contenant le manifeste suivant.MF

test 1.pot Manifeste-Version: 1.0 Forfait-Description: forfait utilisé pour les essais Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee=JavaSE; version = " 1.8" Créé Par: 1.8.0_131 (Oracle Corporation)

test 2.pot: Manifeste-Version: 1.0 Forfait-Description: forfait utilisé pour les essais 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))" Créé Par: 1.8.0_131 (Oracle Corporation)

Comme vous pouvez le voir les deux les faisceaux ne diffèrent que par la version de faisceau et la façon dont la capacité requise est spécifiée.

Le résultat est: test1.jar s'installe parfaitement test2.jar produit le message d'exigence manquant 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. Il n'est pas pris en charge, est-il quelque chose que je dois configurer pour activer les filtres? Evidemment ce n'est pas parce que mon cadre n'est pas configuré pour avoir les osgi.ee Capacité (Test 1.pot de travaux).

évidemment, cela signifie que si je corrige L'en-tête Require-Capability dans les paquets défectueux, j'ai une solution. (Pas une bonne solution si vous installez vos paquets à partir d'un dépôt ouvert.)

j'ai trouvé le problème dans le Felix 5.6.10 version qui était la cause de mon problème:

"capacité requise manquante exigence-capacité: 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 la 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);

changé la dernière ligne:

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

la raison pour laquelle cela pose 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 contructeur du ManifestParser lance une exception se plaignant qu'une capacité exportée ne peut pas être vide. Cette virgule supplémentaire dans le syspkgs a fait penser à l'analyseur qu'une certaine capacité manquait.

et une fois que vous échouez dans ce bloc d'essai vous n'obtenez pas votre hôte osgi.ee capacités ajoutées à votre cadre, ce qui signifie que vous ne pouvez pas résoudre des requêtes comme (&(osgi.ee=JavaSE) (version=1.8))

Juste pour être clair, c'est la version spécifique, je fais référence à:

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. Donc cela pourrait expliquer pourquoi certaines personnes voient ce problème et d'autres pas.

j'ai appliqué le patch et les déclarants fonctionnent à nouveau.