Java 8 & Manque de capacité de Besoin-Capacité: osgi.ee; filter=“(&(osgi.ee=JavaSE)(version=1.8))”

Partager mon expérience sur la rénovation d'une plate-forme cible basée sur Juno 3.8.2 pour exécuter JUnit plugin tests avec Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8:

Échec de l'approche 1: Fragment

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

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

À l'aide de -Dorg.osgi.framework.system.capabilities comme indiqué dans Christian 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 Équinoxe

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

1. De copier le fichier <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile à 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, ce qui 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

Toutefois, cette solution nécessite l'hébergement de votre propre P2 référentiel contenant les org.eclipse.osgi ensemble ou l'application d'un patch à chaque espace de travail du bundle de la piscine.

Discussion

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

Je suis actuellement conscients de deux inconvénients:

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

Sans doute, de la PDE évalue BREE et définit compilateur du niveau de la source en conséquence, ce qui se traduit par "1.7" pour Java 8 sources. Il est possible que d'autres inhibiteurs de la PDE caractéristiques (fonction d'exportation, exportation de produits) peuvent présenter le même problème.

À l'aide de Eclipse Tycho, il est possible de remplacer manuellement les javac au niveau de la source au lieu d'évaluer un paquet de BREE (pour sélectionner un JDK pour compiler avec). Cependant, aussi Tycho est toujours conforme à la donnée du niveau de la source vs BREE et refuse de compiler Java 8 code (testé avec Tycho 0.22).

Aussi, la méthode 2 ne sera probablement pas travailler avec des inhibiteurs de la PDE du faisceau à l'exportation, au moins je ne suis pas au courant de la possibilité de passer VM arguments.

Mise à jour 29.05.2015

Nous sommes allés à l'approche 3 et corrigés avec succès notre plate-forme cible pour utiliser Java 8 avec Eclipse 3.8.

Comme nous l'avons déjà maintenir notre propre P2 référentiel avec tous 3.8 à base de plug-ins Eclipse, nous avons besoin de:

• créer une copie mise à jour de org.eclipse.osgi (nécessaires à la bande de signature d'informations à partir de bundle ainsi)
• créer un patch correctifs org.eclipse.rcp fonctionnalité avec la mise à jour org.eclipse.osgi bundle
• publier de nouveaux 3.8-P2 référentiel d'être consommés par nos postes de travail et serveur de build.

Résumé

Si vous gérez votre propre P2 référentiel pour servir une plateforme cible personnalisée au lieu d'utiliser toute Éclipse.org-fonction de mise à jour du site, il est possible de faire Eclipse 3.8 travailler avec Java 8.

Références: Eclipse Bug à l'appui osgi.ee

Une solution facile est d'inclure org.eclipse.équinoxe.ds (équinoxe déclarative des services). Que le pack runtime exportations de la nécessaire osgi.extender et semble ne déclenchent pas de dépendances supplémentaires.

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

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

"Manque de capacités Nécessitent-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 il cause un problème, c'est que, 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 de la ManifestParser constructeur d'appel déclenche une exception qui se plaint qu'un exportés de la capacité ne peut pas être vide. Que virgule supplémentaire dans le syspkgs fait l'analyseur pense que d'une certaine capacité manquait.

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

Juste pour être clair, il s'agit de la version que je fais référence:

org.apache.felix:org.apache.felix.framework:5.6.10

Ce problème se produit uniquement si vous en ajoutant des capacités du système à 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 sont une fois de plus de travail.