estructura del paquete del paquete OSGi

Question

He estado pensando acerca de algunos "buenas prácticas" en relación con la estructura de paquete dentro de los paquetes de OSGi. Actualmente, en promedio, tenemos como 8-12 clases por paquete. Uno de mi iniciativa / propuesta ha sido la de tener dos paquetes; com.company_name.osgi.services.api (para las clases relacionadas con api-/ interfaces (que se exportan desde el exterior) y com.company_name.osgi.services.impl un paquete de aplicación (no exportado)). ¿Cuáles son los pros los contras de esto? ¿Alguna otra sugerencia?

Answer 1

También puede considerar que pone en las interfaces com.company_name.subsystem, y la puesta en práctica de com.company_name.subsystem.impl, el código específico OSGi, si hay alguna, podría estar en com.company_name.subsystem.osgi. En algún momento es posible que tenga múltiples aplicación de las mismas interfaces. En este caso, usted podría considerar - com.company_name.subsystem.impl1 y com.company_name.subsystem.impl2, por ejemplo:

com.company.scm        // the scm api
com.company.scm.git    // its git implementaton
com.company.scm.svn    // its subversion implementation
com.company.scm.osgi   // the place to put an OSGI Activator

En este sentido la estructura del paquete podría ser agnóstico OSGi, si más adelante en movimiento a un contenedor distinto, sólo hay que poner un adicional

com.company.scm.sca     // or whatever component model you might think of

Siempre que tenga api y impl en el nombre del paquete podría ser molesto. En caso de duda el uso impl pero no api.

Answer 2

No es el número de clases que es importante, pero los conceptos. En mi opinión usted debe tener una entidad conceptual en un paquete. En algunos casos, esto podría ser sólo unas pocas clases en otros varios paquetes con 100s de clases.

Lo que es importante es que separe la API y la implementación. Un paquete contiene la API de su concepto y la otra a la aplicación. Como esto puede proporcionar diferentes implementaciones para un API bien definido. En algunos casos, esto podría ser incluso necesario si desea acceder a los servicios de un paquete de forma remota (por ejemplo, usando R-OGSI)

Los paquetes de APIs son utilizados por el intercambio de código y los servicios de los paquetes de implementación mediante el intercambio de servicios. La mejor manera de explorar esas posibilidades es mirar a los ServiceTrackers.

Answer 3

En el caso de que podría tener la aplicación en el mismo paquete, pero todas sus clases "paquete protegido". De esta manera, se puede exportar el paquete y la puesta en práctica no sería visible al exterior, aun cuando no esté utilizando OSGi (sino como un archivo jar regular).