Tengo un proyecto que hace referencia a varias bibliotecas de código abierto, algunas nuevas y otras no tan nuevas. Dicho esto, todos son estables y deseo seguir con mis versiones elegidas hasta que tenga tiempo de migrar a las versiones más nuevas (ayer probé hsqldb 2.0 y contiene muchos cambios de API).¿Cuál es la forma estándar de agrupar bibliotecas dependientes de OSGi?
Una de las bibliotecas que deseo incorporar es Jasper Reports, pero como seguramente sabrán, viene con una montaña de archivos jar auxiliares y solo necesito un subconjunto de la montaña (conocido), por lo tanto estoy planeando para agrupar todas mis bibliotecas dependientes.
Así:
¿Todo el mundo a medida hacen sus propios paquetes OSGi para bibliotecas de código abierto que están utilizando o hay una fuente principal de OSGi versiones de bibliotecas comunes?
Además, estaba pensando que sería mucho más simple para cada uno de mis paquetes simplemente insertar sus frascos dependientes dentro del paquete. es posible? Si elijo incrustar las bibliotecas foc de terceros dentro de un paquete, supongo que tendré que producir 2 archivos jar, uno sin las bibliotecas integradas (para que las bibliotecas se carguen a través del classpath mediante el cargador de clases estándar) y una versión de osgi que incluya la libraryy incorporado, por lo tanto, debería elegir un nombre de paquete como este < <myprojectname> > - < <subproyecto> > -osgi-.1.0.0.jar?
Si no puedo incrustar las bibliotecas de código abierto y elegir agrupar las bibliotecas de código abierto (vía bnd), ¿debo elegir un nombre único para evitar conflictos con un posible paquete oficial? p.ej. < <myprojectname> > - < <3rdpartylibname> > - < <3rdpartylibversion> > .jar?
Mi proyecto no habilitado para OSGi actualmente busca plugins personalizados escaneando las carpetas META-INF en mis varios plugins a través de Service.providers (...). Si voy a OSGi, ¿funcionará este mecanismo?
Los frascos de Spring llevan impreso Spring, además de que parecen ser versiones anteriores de bibliotecas (como la versión 2.0.5 de Jasper Reports). OSGi parece agradable en teoría, pero parece que todo el mundo está construyendo sus propios paquetes (incluido Spring), lo que de alguna manera frustra el propósito. Por no mencionar el problema de JDBC con OSGi. DLL El infierno se resolvió con classpath. El infierno de Classpath fue resuelto con OSGi. ¿Qué nos salvará del paquete de OSGi infierno? – Chris
@Chris: es bastante cierto en cuanto a la denominación, pero como no existe una autoridad central para proporcionar los paquetes y el propietario no los está creando, parece un compromiso razonable. Al menos sabes de dónde vino, y no hace ninguna diferencia una vez que se implementa. En cuanto a su utilidad, es solo otra herramienta en el cinturón, bastante útil para construir sistemas de tipo conectable. – Robin
La idea de utilizar spring repo como fuente de complementos externos de rcp es excelente, pero ¿dónde puedo encontrar la URL del sitio repo/update que necesito agregar a mi definición de destino? Traté de googlearlo pero no pude encontrar una URL funcional. Sé que agregar la url a la respuesta pronto será obsoleta. Pero definitivamente ayudaría y tal vez otros lo actualizarán en el futuro ... – Jens