eclipse photon

Java 8 y falta la capacidad requerida Require-Capability: osgi.ee; filter=“(&(osgi.ee=JavaSE)(version=1.8))” (8)

He estado utilizando Eclipse Luna win32.x86_64 runing con Java 8.

Aquí desde el Help Menu > About > Installation Detail > Configuration Tab :

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

He creado un nuevo proyecto de plug-in, solicitando JavaSE-1.8 como entorno de ejecución:

En el myplugin/META-INF/MANIFEST.MF tengo, por supuesto:

Bundle-RequiredExecutionEnvironment: JavaSE-1.8

Yo uso este plugin en un archivo de producto. Cuando intento validarlo, obtengo el siguiente error:

Por supuesto que si comienzo el producto, obtengo:

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

He tratado de verificar mucho:

Preferencias> Java> JREs instalados

Preferencias> Java> JRE instalados> Entornos de excución

Preferencias> Java> Compilador: Cumplimiento de JDK Compilador nivel de cumplimiento

Cuando inicio el producto, verifiqué en la pestaña Lanzamiento que utilizo el jre8 como entorno de ejecución.

Incluso he intentado cambiar el Java Runtime Environment en el Run Configurations diálogo Run Configurations :

He intentado diferentes configuraciones Ninguno de ellos funciona.

¿Qué está mal?

¿Es un problema conocido?

Compartiendo mi experiencia en la actualización de una plataforma de destino basada en Juno 3.8.2 para ejecutar las pruebas del complemento JUnit con Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8 :

Enfoque fallido 1: Fragmento

Creando un fragmento para org.eclipse.osgi con un encabezado de Provide-Capability provisión en el manifiesto:

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"

Esta capacidad nunca fue recogida.

Enfoque fallido 2: parámetro de inicio

Usar -Dorg.osgi.framework.system.capabilities como se describe en la respuesta de Christian.

En primer lugar, el argumento debe ser citado correctamente:

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

Este enfoque podría haber funcionado para cualquier otro caso de uso que no sea pde.junit . Todavía tengo esta excepción (ligeramente diferente):

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

Enfoque de trabajo 3: Equinoccio de parches

Parche el paquete org.eclipse.osgi para incluir el JavaSE-1.8.profile .

Copie el archivo <LUNA>/plugins/org.eclipse.osgi_3.10.1.v20140909-1633.jar/JavaSE-1.8.profile al paquete de org.eclipse.osgi del grupo de paquetes de la plataforma de destino.
(por ejemplo, <myworkspace>/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/org.eclipse.osgi_3.8.2.v20130124-134944.jar/JavaSE-1.8.profile )
Perfil de referencia en profile.list (en realidad, esto parece ser opcional):
agrega JavaSE-1.8.profile,/ a .metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/org.eclipse.osgi_3.8.2.v20130124-134944.jar/profile.list

Sin embargo, esta solución requiere alojar su propio repositorio P2 que contenga el paquete org.eclipse.osgi o aplicar un parche a cada grupo de paquetes del área de trabajo.

Discusión

Aún así, existe la posibilidad de mantener BREE en "JavaSE-1.7" que sea compatible con la versión existente org.eclipse.osgi 3.8.2.

Actualmente soy consciente de dos inconvenientes:

La exportación de complementos directamente desde Eclipse a través de PDE falla si se usa la sintaxis de Java 8 en el código (por ejemplo, expresiones lambda).
El registro contiene errores del compilador y el resultado compilado es en realidad de diferente tamaño en comparación con un paquete compilado con JavaSE-1.8 BREE.

Presumiblemente, PDE evalúa BREE y establece el nivel de fuente del compilador en consecuencia, lo que da como resultado "1.7" para las fuentes de Java 8. Es posible que otras características de PDE (exportación de características, exportación de productos) puedan presentar el mismo problema.

Usando Eclipse Tycho , es posible anular manualmente el nivel de origen javac en lugar de evaluar el BREE de un paquete (para seleccionar un JDK para compilar con). Sin embargo, también Tycho aún coincide con el nivel de fuente dado vs. BREE y se niega a compilar el código Java 8 (probado con Tycho 0.22).

Además, es probable que el enfoque 2 no funcione con la exportación de paquetes de PDE, al menos no conozco ninguna posibilidad de pasar argumentos de VM.

Actualización 29.05.2015

Fuimos con el enfoque 3 y parcheamos con éxito nuestra plataforma objetivo para usar Java 8 junto con Eclipse 3.8.

Como ya mantenemos nuestro propio repositorio P2 con todos los complementos de Eclipse basados en 3.8, necesitamos:

crear una copia actualizada de org.eclipse.osgi (necesaria también para eliminar la información de firma del paquete)
cree un parche de características que parche la característica org.eclipse.rcp con el paquete org.eclipse.osgi actualizado
publique el nuevo repositorio P2 basado en 3.8 para que sea consumido por nuestras estaciones de trabajo y servidor de compilación.

Resumen

Si mantiene su propio repositorio P2 para servir a una plataforma de destino personalizada en lugar de utilizar cualquier sitio de actualización basado en Eclipse.org, es posible hacer que Eclipse 3.8 funcione con Java 8.

Referencias: Eclipse Bug para soportar osgi.ee

El error significa que su paquete tiene una Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" en su manifiesto. Por lo tanto, esto significa que el paquete solo se iniciará cuando exista un paquete que proporcione esta capacidad.

En el caso de la capacidad osgi.ee, es el marco OSGi (equinoccio) el que debe proporcionar esta capacidad. Aparentemente no hace esto.

Entonces, un enfoque sería eliminar el encabezado de tu paquete Manifest. El otro sería hacer que el equinoccio exporte la capacidad. Quizás podrías simplemente probar con la versión más nueva del equinoccio. Aunque no estoy seguro de si esto ayuda. También puede intentar establecer la propiedad del marco (usando -D): org.osgi.framework.system.capabilities = osgi.ee; osgi.ee = "JavaSE"; versión: List = "1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"

Ver

El mismo problema en la lista de eclipse.

Encontré el problema en la versión Felix 5.6.10 que estaba causando mi problema:

"Falta la capacidad requerida Require-Capability: osgi.ee; filter =" (& (osgi.ee = JavaSE) (version = 1.8)) "

Este es el código que crea el problema. Está en el constructor del 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);

cambió la última línea a:

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

La razón por la que causa un problema es que un poco más adelante en el constructor encontramos este código:

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

Sin la corrección, la llamada del conductor ManifestParser lanza una excepción que se queja de que una capacidad exportada no puede estar en blanco. Esa coma adicional en los syspkgs hizo que el analizador pensara que faltaba alguna capacidad.

Y una vez que falla en ese bloque de prueba, no puede agregar las capacidades de su servidor osgi.ee a su marco, lo que significa que no puede resolver solicitudes como (& (osgi.ee = JavaSE) (versión = 1.8))

Para que quede claro, esta es la versión específica a la que me refiero:

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

Este problema solo ocurre si agrega algunas capacidades adicionales del sistema a su configuración como lo hice yo. Así que eso podría explicar por qué algunas personas ven este problema y otras no.

He aplicado el parche y los archivadores vuelven a funcionar.

Encontré una configuración que simplemente funciona, sin mucho trabajo. Selecciona Java 8 en el archivo del producto, la configuración del proyecto y la ruta de compilación. Lo importante es el archivo manifiesto. Aquí tiene que seleccionar tanto Java 8 como Java 7. Aquí también el orden es importante. Java 8 tiene que estar en la parte superior.

Creo que la razón por la que esta configuración está funcionando es que el compilador selecciona el primer JRE y puede manejar la nueva sintaxis de Java 8. Los paquetes de eclipse comprueban si una de las entradas es el Java 7 necesario y también está satisfecho.

Solución real y rápida:

" Edité la pestaña de complementos en la configuración de ejecución y verifiqué org.eclipse.equinox.ds e hice clic en ''Agregar complementos necesarios''. LO HA FIJO " .

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

Tengo el mismo problema: Falta la capacidad requerida Require-Capability: osgi.ee; filter = "(& (osgi.ee = JavaSE) (version = 1.8))

Estoy usando Felix 5.6.10

Esto es algo interesante que descubrí: creé dos paquetes test.jar que contienen el siguiente MANIFEST.MF

test1.jar Manifest-Version: 1.0 Bundle-Description: lote utilizado para probar Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee = JavaSE; version = "1.8" Created-By: 1.8.0_131 (Oracle Corporation)

test2.jar: Manifest-Version: 1.0 Bundle-Description: bundle usado para probar Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.2 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee ; filter: = "(& (osgi.ee = JavaSE) (versión 1.8))" Created-By: 1.8.0_131 (Oracle Corporation)

Como puede ver, los dos paquetes solo difieren en la versión de paquete y en cómo se especifica la capacidad requerida.

El resultado es: test1.jar instala muy bien test2.jar produce el mensaje de requisito faltante cuando intenta instalarlo.

Así que hay algo sobre el uso de un filtro en el encabezado Require-Capability que no funciona en el marco de mi felix osgi. ¿No es compatible, hay algo que deba configurar para habilitar los filtros? Claramente no es porque mi marco no está configurado para tener la capacidad osgi.ee requerida (test1.jar funciona).

Obviamente, eso significa que si corrijo el encabezado Require-Capability en los paquetes con fallas, obtuve una solución alternativa. (No es una buena solución si está instalando sus paquetes desde un repositorio abierto).

Tengo este error en el dxp de liferay. Había cambiado el espacio de trabajo de liferay y está funcionando bien.

Una solución fácil es incluir org.eclipse.equinox.ds (servicios declarativos de equinoccio). Ese paquete de tiempo de ejecución exporta el osgi.extender requerido y parece que no activa dependencias adicionales.