Maven: ¿proyecto 'todo' o 'padre' para la agregación?

Question

Para los fines educativos que han creado un diseño de proyecto como tal (plana con el fin de eclipsar la suite mejor):

-product 
| 
|-parent 
|-core 
|-opt 
|-all 

Padres contiene un proyecto conjunto con el núcleo, optar y todo. Core implementa la parte obligatoria de la aplicación. Opt es una parte opcional. Se supone que todo combina núcleo con opt y tiene estos dos módulos enumerados como dependencias.

Ahora estoy tratando de hacer los siguientes artefactos:

1. producto core.jar
2. producto de núcleo src.jar
3. producto de núcleo-with-dependencies.jar
4. producto-opt.jar
5. producto-opt-src.jar
6. producto-opt-con-dependencies.jar
7. -all.jar producto
8. producto todo-src.jar
9. producto todo-en-dependencies.jar

mayoría de ellos son bastante sencillo de producir. Aunque tengo algunos problemas con los artefactos agregados. He logrado hacer el producto-all-src.jar con un descriptor de ensamblaje personalizado en el módulo 'todo', que descarga las fuentes para todos los productos no transitivos, y esto funciona bien. Esta técnica también me permite crear el producto-todo-con-dependencias.jar.

Sin embargo, recientemente descubrí que puede usar el objetivo de fuente: agregado en el complemento de origen para agregar fuentes de todo el proyecto agregado. Esto también es cierto para el complemento javadoc, que también se agrega a través del uso del proyecto principal.

Así que estoy dividido entre mi enfoque de 'todos' los módulos y abandonando el módulo 'todos' y simplemente uso el módulo 'principal' para toda la agregación. Se siente sucio tener algunos artefactos agregados producidos en 'padre', y otros producidos en 'todo'. ¿Hay alguna manera de crear un contenedor de 'producto-todo' en el proyecto padre, o de agregar javadoc en el proyecto 'todo'? ¿O debería mantener ambos?

Gracias

Answer 1

Los árboles aplastados ya no se usan con frecuencia. Esto se hizo hace varios años para tratar cómo Eclipse manejó los proyectos y la falta de una buena integración de Maven y Eclipse. Si usa m2eclipse para importar proyectos Maven en Eclipse, no tendrá ningún problema con un árbol anidado típico de Maven.

En cuanto a lo que es un buen ejemplo de cómo estructurar una construcción Maven? La fuente del proyecto Maven itself. Tiene todas las piezas que desea, incluido el assembly final que empaqueta los paquetes.

La estructura anidada típica tiene una jerarquía descendente donde el padre realiza la agregación de los módulos que se encuentran debajo de ella, y los elementos secundarios heredan valores del elemento primario. Aunque estos pueden y algunas veces son separados, esta no es la norma.

Answer 2

me gustaría sugerir simplemente mantener el descriptor de montaje de "todos", moverlo a padre/y cambiar padre/pom.xml en consecuencia, a continuación, cree que el montaje haciendo algo como mvn -f parent/pom.xml assembly:assembly. En otras palabras, sí, elimine el proyecto redundante de "todo", ya que solo está duplicando lo que "padre" ya está haciendo.

En una nota al margen, "padre" parece una opción de nomenclatura pobre para ese proyecto si se trata de un proyecto agregado y no solo de un padre pom.xml.

[Editar]

Aunque un proyecto mucho más grande, quizás un proyecto que se presenta cómo estás imaginando es el proyecto de camello Apache. Compruébelo aquí: http://camel.apache.org/source.html. Hay un padre/módulo que maneja todo para todo lo demás, y un módulo separado para producir las distribuciones de compilación reales en apache-camel/(con descriptores de ensamblaje en apache-camel/src // main/descriptors). Tal vez eso sea más de una ayuda.