Hola, hallamos la respuesta a lo que estabas buscando, continúa leyendo y la verás un poco más abajo.
Solución:
Usar OSGi podría ser una buena opción para usted. Permitiría crear módulos fuera de la aplicación. También puede organizar las dependencias de una mejor manera. Si define sus interfaces entre los diferentes módulos correctamente, entonces puede usar la integración continua ya que solo tiene que reconstruir el módulo que afectó en el check-in.
Los mecanismos proporcionados por OSGi lo ayudarán a desenredar el código existente. Debido a la forma en que funciona la carga de clases, también lo ayuda a manejar los parches de una manera más fácil.
Algunos conceptos de OSGi que parecen ser una buena combinación para usted, como se muestra en wikipedia:
El marco se divide conceptualmente en las siguientes áreas:
- Paquetes: los paquetes son componentes jar normales con encabezados de manifiesto adicionales.
- Servicios: la capa de servicios conecta paquetes de forma dinámica al ofrecer un modelo de publicación, búsqueda y vinculación para objetos Java simples (POJO).
- Registro de servicios: la API para los servicios de gestión (ServiceRegistration, ServiceTracker y ServiceReference).
- Ciclo de vida: la API para la gestión del ciclo de vida (instalar, iniciar, detener, actualizar y desinstalar paquetes).
- Módulos: la capa que define la encapsulación y la declaración de dependencias (cómo un paquete puede importar y exportar código).
- Seguridad: la capa que maneja los aspectos de seguridad al limitar la funcionalidad del paquete a capacidades predefinidas.
Primero: buena suerte y buen café. Necesitarás ambos.
Una vez tuve un problema similar. Código heredado con terribles dependencias circulares, incluso entre clases de diferentes paquetes como org.example.pkg1.A depende de org.example.pk2.B y viceversa.
Empecé con maven2 y nuevos proyectos de eclipse. Primero traté de identificar las funcionalidades más comunes (capa de registro, interfaces comunes, servicios comunes) y creé proyectos maven. Cada vez que estaba satisfecho con una pieza, implementaba la biblioteca en el repositorio de Central Nexus para que estuviera disponible casi de inmediato para otros proyectos.
Así que trabajé lentamente a través de las capas. maven2 manejó las dependencias y el complemento m2eclipse proporcionó una útil vista de dependencia. Por cierto, por lo general, no es demasiado difícil convertir un proyecto de eclipse en un proyecto experto. m2eclipse puede hacerlo por usted y solo tiene que crear algunas carpetas nuevas (como src/main/java) y ajustar la ruta de compilación para las carpetas de origen. Toma solo un minuto o dos. Pero espere más dificultades, si su proyecto es un complemento de eclipse o una aplicación rcp y desea que maven no solo administre artefactos sino también cree e implemente la aplicación.
En opinión, Eclipse, Maven y Nexus (o cualquier otro administrador de repositorios de Maven) son una buena base para comenzar. Tienes suerte, si tienes una buena documentación de la arquitectura del sistema. y esta arquitectura está realmente implementada;)
Tuve una experiencia similar en una base de código pequeña (40 kloc). No hay °reglas”:
- compilado con y sin un “módulo” para ver su uso
- Partí de “módulos hoja”, módulos sin otras dependencias
- Manejé dependencias cíclicas (esta es una tarea muy propensa a errores)
- con maven hay una gran cantidad de documentación (informes) que se puede implementar en su proceso de CI
- con maven siempre puede ver qué usa qué tanto en el sitio tanto en netbeans (con un
muy buen gráfico dirigido) - con maven puede importar código de biblioteca en su base de código, aplicar parches de código fuente y compilar con sus productos (a veces esto es muy fácil, a veces es muy difícil)
Compruebe también el Analizador de dependencias:
(fuente: javalobby.org)
Frijoles netos:
(fuente: zimmer428.net)
Al final de todo puedes encontrar las crónicas de otros programadores, tú además tienes el poder dejar el tuyo si dominas el tema.