¿Cómo incluir una dependencia a un archivo jar de una aplicación eclipse/osgi?

Question

Creé una aplicación Eclipse 4 y necesitaba una jar ofreciendo una funcionalidad como parte de mi aplicación (esto podría ser cualquier cosa, por ejemplo, log4j para hacerlo trivial).
Agregué el jar como parte del classpath de mi proyecto (Right Click->Configure Build Path) pero en el tiempo de ejecución mi servicio falló con un error ClassNotFound (de OSGI, supongo?).
De todos modos, al buscar esto resultó, al menos como lo he entendido, que debería agregar el contenedor como parte de otro Plugin y crear una dependencia desde mi aplicación/servicio a este nuevo complemento.
I.e. Creé un Plugin Project from Existing JAR archives.
Esta vez la configuración funcionó.
Entonces, si entiendo esto, al desarrollar para Eclipse/OSGi no deberíamos agregar jars en los classpaths directamente, sino agregarlos a través de complementos (¿por qué?).
Pregunta: Si estoy en lo correcto hasta ahora, ¿cuál es la práctica estándar para incluir jars al desarrollar un proyecto?
Definir/Crear una Plugin Project from existing JAR archives y añadir todos los las bibliotecas de terceros requeridas necesarios allí, o tienen un proyecto de plug-in diferente por necesaria jar o tal vez algo más ???
Lo siento si mi terminología no es precisa. Soy nuevo en OSGi y Eclipse programación

Nota: Cuando se habla dejars No estoy refiriendo a otros servicios OSGi. Me refiero a la norma de usar bibliotecas de terceros listas y confiables que serían necesarias en muchas partes de una aplicación. P.ej. log4j o una biblioteca de análisis xml o apache commons etc.

Answer 1

Los ejemplos que ha mencionado están disponibles como paquetes OSGi, por lo que no es necesario que los haga usted mismo. Normalmente no usa dependencias de jar directo en OSGi, normalmente usa dependencias de paquetes o paquetes. En el ejemplo de log4j al que se refiere, debe usar el paquete de importación , ya que puede haber múltiples proveedores de paquetes (nuevo log4j jar, versión de springsource incluida de la implementación anterior de log4j, slf4j ...). Esto desconectará tus dependencias de código del proveedor real.

Estas dependencias se mantienen a través de su manifiesto, no su clase de proyecto. En un proyecto de complemento eclipse, el classpath de compilación de proyectos se deriva de las entradas en el manifiesto.

Aunque no esté utilizando servicios, todas las dependencias de código se mantienen aún a través del manifiesto.

Answer 2

Para el tiempo de ejecución siempre es el Manifiesto y los encabezados allí que controlan lo que está en el paquete classpath. Hay tres formas de obtener acceso a un jar:

1. Cabecera del Importación-Paquete. Esta es la forma recomendada. Usted define una importación por paquete que necesita. El archivo jar al que desea acceder debe desplegarse en el tiempo de ejecución como un paquete. También necesita exportar todos los paquetes necesarios.

2. Require-Bundle. Esta es otra forma de acceder a los paquetes. Usted define la identificación del paquete que necesita y ve todos los paquetes que exporta. Como Require-Bundle lo vincula más estrechamente con el otro paquete, se debe preferir el modo Importar-Paquetes.

3. Bundle-Classpath. Esto permite agregar jar a su classpath que incrusta en su propio paquete. Esto solo debería ser un último recurso cuando a la inversa no funciona. Puede tener desagradables problemas de carga de clases al mezclar esto con los otros métodos.

Puedes encontrar muchos paquetes preconstruidos en maven central. Muchos tarros de hoy ya contienen un manifiesto OSGi. Para los casos donde esto no es cierto, muchos paquetes se vuelven a empaquetar como paquetes por servicemix. Consulte groupId: org.apache.servicemix.bundles. También está el repositorio de paquetes de primavera donde puede encontrar más.

A continuación he enumerado algunos recursos que tal vez quiera leer:

http://www.aqute.biz/Blog/2007-02-19

http://wiki.osgi.org/wiki/Import-Package

http://wiki.osgi.org/wiki/Require-Bundle

http://www.vogella.com/blog/2009/03/27/required-bundle-import-package/

Answer 3

Extactaly mismo problema que enfrentamos en nuestro proyecto. tenemos algún contenedor heredado que no es compatible con OSGi, creamos una carpeta lib paralela a BundleContent y la agregamos a la sección classpath del manifiesto.

Bundle-ClassPath: ., 

/lib/<legacy jar>.jar 

No hay necesidad de exportación e importación de paquetes innecesariamente si sólo hay un paquete va a consumirlo,