Estructura del paquete del paquete OSGi

Question

He estado pensando en algunas "buenas prácticas" con respecto a la estructura del paquete dentro de los paquetes de osgi. Actualmente, en promedio, tenemos como 8-12 clases por paquete. Una de mis iniciativas/propuestas ha sido tener dos paquetes; com.company_name.osgi.services.api (para clases/interfaces relacionadas con API (que se exporta externamente) y un paquete com.company_name.osgi.services.impl para implementación (no exportado)). ¿Cuáles son las ventajas de esto? ¿Cualquier otra sugerencia?

Answer 1

También podría considerar poner las interfaces en com.company_name.subsystem, y la implementación en com.company_name.subsystem.impl, el código específico de OSGI, si hay alguno, podría estar en com.company_name.subsystem.osgi. En algún momento puede tener una implementación múltiple 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 esta estructura de paquetes sentido 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 

Tener siempre api y impl en el nombre de su paquete podría ser molesto. Si tiene dudas, use impl pero no api.

Answer 2

No es la cantidad de clases lo que importa, sino los conceptos. En mi opinión, debe tener una entidad conceptual en un paquete. En algunos casos, esto podría ser solo unas pocas clases en otros varios paquetes con cientos de clases.

Lo importante es que separes la API y la implementación. Un paquete contiene la API de su concepto y el otro la implementación. De esta manera puede proporcionar diferentes implementaciones para una API bien definida. En algunos casos, esto puede ser necesario incluso si desea acceder a los servicios desde un paquete de forma remota (utilizando, por ejemplo, R-OGSi)

Los paquetes de API se utilizan luego compartiendo el código y los servicios de los paquetes de implementación compartiendo el servicio. La mejor forma de explorar esas posibilidades es mirar ServiceTrackers.

Answer 3

En su caso, podría tener la implementación en el mismo paquete, pero todas sus clases "paquete protegido". De esta forma, puede exportar el paquete y la implementación no sería visible desde el exterior, incluso cuando no se use OSGi (sino como un archivo jar normal).