¿Por qué y cuándo crear un proyecto Maven de varios módulos?

Question

Tengo una pregunta general sobre el proyecto de múltiples módulos de Maven. ¿Cuándo y por qué ir por ello?

Answer 1

La respuesta de @Esko Luontola

Dividir el proyecto en múltiples módulos es útil por ejemplo si los módulos necesitan ser desplegados por separado, ..

podría ser mal interpretada. Si tiene módulos que se implementarán por separado, es exactamente lo contrario. En tal caso, nunca debe crear una compilación de varios módulos. Esto debe hacerse a través de proyectos maven separados y sencillos.

La idea de una compilación de varios módulos es si tiene módulos que pertenecen juntos como un proyecto de oído que generalmente consta de varios otros como cliente, servidor, ejb, guerra, etc. Esto generalmente se maneja a través de un módulo múltiple build, lo que significa que todos los módulos tienen el mismo número de versión, pero se puede acceder y usar por separado.

Answer 2

La división del proyecto en múltiples módulos es útil, por ejemplo, si los módulos deben implementarse por separado o, en el caso de una biblioteca, algunos consumidores necesitan solo un subconjunto de las clases o los desarrolladores de la biblioteca desean hacer una distinción clara entre lo que es API pública y lo que es implementación privada. Y con grandes proyectos, puede hacer que el código sea más fácil de mantener en orden, incluso si el código podría estar técnicamente en el mismo módulo.

Answer 3

hay algunos casos más de uso en el que voy a recomendar el uso de múltiples proyecto de módulo experto:

1. Sus módulos comparten las mismas dependencias, en este caso va a especificar todas las dependencias en el pom principal, y todos los módulos pueden disfrutarlo. (No es necesario especificar para cada módulo las mismas dependencias).

2. Si necesita realizar operaciones en múltiples proyectos todos juntos. (Yo personalmente lo uso), creo un paquete de todos mis proyectos, y lo envío a un cliente, por lo que los construyo usando el pom principal, y los paquete como archivo zip usando otro plugin maven.

Answer 4

Parece que esta pregunta es más sobre el software en general. Maven es solo una forma de hacerlo.

voy a qoute unas pocas líneas de "Continuous Delivery", by Jez Humble

Qué es un componente? Este es un término terriblemente sobrecargado en el software, , por lo que trataremos de dejarlo lo más claro posible a lo que nos referimos. Cuando hablamos de componentes, nos referimos a una estructura de código razonable a gran escala dentro de una aplicación, con una API bien definida, que podría ser potencialmente intercambiada para otra implementación. Un sistema de software basado en componentes se distingue por el hecho de que la base de código se divide en piezas discretas que proporcionan un comportamiento a través de interacciones limitadas bien definidas con otros componentes. La antítesis de un sistema basado en componentes es un sistema monolítico sin límites claros o separación de preocupaciones entre los elementos responsables de diferentes tareas.Los sistemas monolíticos suelen tener pobre encapsulación, y el acoplamiento hermético entre estructuras lógicamente independientes rompe la Ley de Demeter.

...

El empleo de un diseño basado en componentes a menudo se describe como el fomento de la reutilización y el buenas propiedades arquitectónicas tales como el acoplamiento débil. Este es cierto, pero también tiene otro beneficio importante: es una de las formas más eficientes de para que equipos grandes de desarrolladores colaboren.

...

Muchos proyectos están muy bien con un único repositorio de control de versiones y una tubería de la instalación sea sencilla . Sin embargo, muchos proyectos se han convertido en un marasmo de código no conservado porque nadie tomó la decisión de crear componentes discretos cuando era barato hacerlo. El punto en que los proyectos pequeños cambian en uno más grande es fluido y le escapará .

...

Por último, vale la pena señalar la ley de Conway, que establece que “ organizaciones que los sistemas de diseño. . . están obligados a producir diseños que son copias de las estructuras de comunicación de estas organizaciones . "4 Por lo tanto, por ejemplo, los proyectos de código abierto donde los desarrolladores se comunican solo por correo electrónico tienden a ser muy modulares con pocas interfaces . Un producto desarrollado por un equipo pequeño y coubicado tenderá a a estar estrechamente acoplado y no modular. Tenga cuidado de cómo configura su equipo de desarrollo, ya que afectará la arquitectura de su aplicación .

Me parece increíble lo lúcido y preciso que es esta última afirmación. ¡Y recomiendo ese libro! :-)