Paquetes propietarios que no son OSGi necesarios en la aplicación OSGi: no se pueden redistribuir

Question

Deseo utilizar los archivos patentados que no sean OSGi en un entorno OSGi. Para el desarrollo, simplemente lo re-empaquetamos/exportamos con el paquete Maven plugin [1]. El problema es que, por razones legales, no podremos redistribuir estos paquetes a nuestro cliente, lo que matará tanto la integración como el reempaquetado, que son (AFAIK) las únicas opciones (ver [2]).

Antes de usar OSGi, teníamos una sección en nuestro manual que describe cómo poner estos archivos en una carpeta de la biblioteca después de adquirirlos en los propios. Dadas las reglas de OSGi para resolver clases, obviamente esto ya no funcionará.

Estoy en lo correcto asumir que la única manera de resolver esto es legal, es decir, obtener una licencia de redistribución del proveedor de los paquetes (que puede ser una pesadilla beurocratic e impedir la entrega a tiempo), o me estoy perdiendo un técnico ¿solución?

[1] How can I share non-OSGi libraries between bundles in an OSGi container?

[2] Non-osgi library usage in an osgi application

Answer 1

Simplemente agregaría este JAR al classpath principal de la aplicación Java, usando su ubicación existente en una carpeta de biblioteca como ya lo ha establecido. Luego puede exportar los paquetes que necesita a OSGi usando la propiedad org.osgi.framework.system.packages.extra.

Answer 2

servicios remotos Quizás OSGi (distributed OSGi) podrían ser una respuesta. Usted alojaría el entorno OSGi que expone la lib propietaria, e instalará el resto en la máquina del cliente.

Answer 3

He visto este requisito también en un proyecto comercial. Terminamos agregando un paquete especial, que al inicio descargó los archivos necesarios de los sitios relevantes y los agregó a nuestros paquetes de reexportación.

Así

• tenemos un frasco de 3 ª parte no OSGi J.jar la que queremos usar
• añadimos un (casi) vacío paquete OSGi con dos archivos
  • un META-INF/MANIFEST.MF que re -exporta todos los paquetes relevantes de J.jar
  • un archivo de texto simple - META-INF/DOWNLOADS - que especifica desde donde podemos descargar J.jar
• tenemos un paquete OSGi genérico simple (con un nivel de inicio temprano) que pasa por todos los paquetes instalados y comprueba si existe META-INF/DOWNLOADS. Si lo hace, descarga los archivos jar especificados si aún no están presentes.

Cuando el paquete de reexportación se inicie más tarde, parecerá que distribuimos el contenedor infractor ... y todos están contentos.

Cuando necesitábamos una nueva versión del jar, acabamos de lanzar una nueva versión de nuestro jar como lo haríamos normalmente. Los problemas principales eran cómo manejar cualquier problema en el proceso de descarga.

Answer 4

Esto es bastante filosófico. ¿Qué constituye exactamente una distribución de contenido digital?

(1) Todos estamos de acuerdo en que si el contenedor en cuestión está incluido en la descarga de instalación, se trata de una redistribución.

(2) ¿Qué pasa si el programa de instalación es una capa delgada, cuando se ejecuta, descarga más cosas de Internet. Si descarga el jar de su servidor, creo que la mayoría de la gente estaría de acuerdo en que esto es esencialmente lo mismo que (1), y es una redistribución.

(3) ¿Qué ocurre si el shell de instalación descarga el contenedor desde el servidor del propietario? Supongamos que está automatizado sin conocimiento del usuario final.

¿Podría alguien realmente argumentar que (3) es muy diferente de (2), y es no una redistribución?

Creo que es, para todos los efectos. Estamos distribuyendo efectivamente el contenedor con nuestro programa, la forma en que se hace bajo el capó no es relevante con respecto al espíritu de la licencia de redistribución. Quien obtiene el programa se lleva la jarra, eso es un hecho.

Al menos deberíamos contactar al autor para verificar que está de acuerdo con él. Debemos respetar los softwares gratuitos, no los utilice de forma contraria a la voluntad de los autores.