java - plugin - Maven padre pom vs módulos pom

maven-jar-plugin executable jar (4)

Un padre independiente es la mejor práctica para compartir la configuración y las opciones a través de componentes no acoplados. Apache tiene un proyecto pom principal para compartir avisos legales y algunas opciones de empaquetado comunes.
Si su proyecto de nivel superior tiene un trabajo real en él, como agregar javadoc o empaquetar un lanzamiento, entonces tendrá conflictos entre la configuración necesaria para realizar ese trabajo y la configuración que desea compartir a través del padre. Un proyecto solo para padres evita eso.
Un patrón común (ignorando # 1 por el momento) es hacer que los proyectos con código utilicen un proyecto principal como su principal, y que use el nivel superior como principal. Esto permite que todos compartan las cosas básicas, pero evita el problema descrito en el # 2.
El complemento del sitio se confundirá mucho si la estructura principal no es la misma que la estructura de directorios. Si desea crear un sitio agregado, deberá hacer algunos trucos para evitar esto.
Apache CXF es un ejemplo del patrón en # 2.

Parece que hay varias formas de estructurar a los padres poms en una construcción de multiproyectos y me pregunto si alguien tuvo alguna idea sobre cuáles son las ventajas / inconvenientes de cada forma.

El método más simple de tener un pom principal sería ponerlo en la raíz de un proyecto, es decir

myproject/ myproject-core/ myproject-api/ myproject-app/ pom.xml

donde pom.xml es tanto el proyecto principal como describe los módulos -core -api y -app

El siguiente método es separar el padre en su propio subdirectorio como en

myproject/ mypoject-parent/ pom.xml myproject-core/ myproject-api/ myproject-app/

Donde el pom principal todavía contiene los módulos pero son relativos, por ejemplo ../myproject-core

Finalmente, existe la opción donde la definición del módulo y la matriz se separan como en

myproject/ mypoject-parent/ pom.xml myproject-core/ myproject-api/ myproject-app/ pom.xml

Donde el pom principal contiene cualquier configuración "compartida" (dependencyManagement, propiedades, etc.) y el myproject / pom.xml contiene la lista de módulos.

La intención es ser escalable a una construcción a gran escala, por lo que debe ser escalable a una gran cantidad de proyectos y artefactos.

Algunas preguntas adicionales:

¿Dónde está el mejor lugar para definir las diversas configuraciones compartidas como en el control de origen, los directorios de implementación, los complementos comunes, etc.? (Supongo que el principal, pero a menudo me ha mordido esto y terminaron en cada proyecto en lugar de uno común).
¿De qué manera el plugin de Maven release, hudson y nexus se relacionan con la forma en que configura sus proyectos múltiples (posiblemente una pregunta gigante, es más si alguien ha sido descubierto cuando por la forma en que se creó una construcción de proyectos múltiples)?

Edición: Cada uno de los subproyectos tiene su propio pom.xml, lo he dejado fuera para mantenerlo terso.

Desde mi experiencia y las mejores prácticas de Maven hay dos tipos de "padres poms"

pom principal de "empresa": este pom contiene información y configuración específicas de su compañía que heredan cada pom y no es necesario copiarlos. Estas informaciones son:
- repositorios
- secciones de gestión de distribución
- Configuraciones de complementos comunes (como las versiones de origen y destino de compilador-compilador-maven)
- organización, desarrolladores, etc
La preparación de este pom para padres debe hacerse con precaución, ya que todos los poms de su compañía heredarán de ella, por lo que este pom debe ser maduro y estable (¡la liberación de una versión de pom para padres no debería afectar la liberación de todos los proyectos de su compañía!)
El segundo tipo de padre pom es un padre multimodular. Prefiero su primera solución: esta es una convención por defecto de Maven para proyectos de múltiples módulos, muy a menudo representa la estructura de código VCS

La intención es ser escalable a una construcción a gran escala, por lo que debe ser escalable a una gran cantidad de proyectos y artefactos.

Los mutliproyectos tienen una estructura de árboles, por lo que no se reduce a un nivel de pom principal. Trate de encontrar un proyecto adecuado para sus necesidades: un ejemplo clásico es cómo descifrar proyectos de mutimodules

distibution/ documentation/ myproject/ myproject-core/ myproject-api/ myproject-app/ pom.xml pom.xml

Algunas preguntas adicionales:
¿Dónde está el mejor lugar para definir las diversas configuraciones compartidas como en el control de origen, los directorios de implementación, los complementos comunes, etc.? (Supongo que el principal, pero a menudo me ha mordido esto y terminaron en cada proyecto en lugar de uno común).

Esta configuración debe dividirse de manera inteligente en un pom principal de "compañía" y uno o más pom (es) principal de proyecto. Las cosas relacionadas con todo lo que proyectas van al padre de la "empresa" y esto relacionado con el proyecto actual va al proyecto.

¿De qué manera el plugin de Maven release, hudson y nexus se relacionan con la forma en que configura sus proyectos múltiples (posiblemente una pregunta gigante, es más si alguien ha sido descubierto cuando por la forma en que se creó una construcción de proyectos múltiples)?

El padre de la empresa pom tiene que ser liberado primero. Para multiproyectos se aplican reglas estándar. El servidor de CI necesita saber todo para construir el proyecto correctamente.

En mi opinión, para responder a esta pregunta, debe pensar en términos del ciclo de vida del proyecto y el control de versiones. En otras palabras, ¿el pom principal tiene su propio ciclo de vida, es decir, puede lanzarse por separado de los otros módulos o no?

Si la respuesta es afirmativa (y este es el caso de la mayoría de los proyectos que se han mencionado en la pregunta o en los comentarios), entonces el pom principal necesita su propio módulo desde un VCS y desde un punto de vista de Maven y terminará con algo como esto en el nivel VCS:

Esto hace que el proceso de pago sea un poco doloroso y una forma común de lidiar con eso es usar svn:externals . Por ejemplo, agregue un directorio de trunks :

Con la siguiente definición externa:

parent-pom http://host/svn/parent-pom/trunk projectA http://host/svn/projectA/trunk

Una verificación de trunks resultaría en la siguiente estructura local (patrón # 2):

root/ parent-pom/ pom.xml projectA/

Opcionalmente, incluso puede agregar un pom.xml en el directorio de trunks :

Este pom.xml es un tipo de pom "falso": nunca se libera, no contiene una versión real, ya que este archivo nunca se libera, solo contiene una lista de módulos. Con este archivo, una verificación resultaría en esta estructura (patrón # 3):

root/ parent-pom/ pom.xml projectA/ pom.xml

Este "truco" permite iniciar una construcción de reactor desde la raíz después de un proceso de pago y hacer las cosas aún más prácticas. En realidad, así es como me gusta configurar proyectos de Maven y un repositorio de VCS para grandes compilaciones : simplemente funciona, se adapta bien, brinda toda la flexibilidad que pueda necesitar.

Si la respuesta es no (volviendo a la pregunta inicial), entonces creo que puedes vivir con el patrón # 1 (haz lo más simple que podría funcionar).

Ahora, sobre las preguntas de bonificación:

¿Dónde está el mejor lugar para definir las diversas configuraciones compartidas como en el control de origen, los directorios de implementación, los complementos comunes, etc.? (Supongo que el principal, pero a menudo me ha mordido esto y terminaron en cada proyecto en lugar de uno común).

Honestamente, no sé cómo no dar una respuesta general aquí (como "usa el nivel en el que crees que tiene sentido para mutualizar las cosas"). Y de todos modos, los poms infantiles siempre pueden anular las configuraciones heredadas.

¿De qué manera el plugin de Maven release, hudson y nexus se relacionan con la forma en que configura sus proyectos múltiples (posiblemente una pregunta gigante, es más si alguien ha sido descubierto cuando por la forma en que se creó una construcción de proyectos múltiples)?

La configuración que utilizo funciona bien, nada particular que mencionar.

En realidad, me pregunto cómo el complemento de release de maven trata con el patrón # 1 (especialmente con la sección <parent> , ya que no puede tener dependencias de SNAPSHOT en el momento de la publicación). Esto suena como un problema de huevo o gallina, pero no puedo recordar si funciona y fue demasiado perezoso para probarlo.

Hay una pequeña trampa con el tercer enfoque. Dado que los POM agregados (myproject / pom.xml) por lo general no tienen ningún elemento principal, no comparten la configuración. Eso significa que todos esos POM agregados tendrán solo repositorios predeterminados.

Eso no es un problema si solo usa complementos de Central, sin embargo, esto fallará si ejecuta el complemento usando el formato plugin: goal desde su repositorio interno. Por ejemplo, puede tener foo-maven-plugin con el ID de org.example de org.example proporciona el objetivo generate-foo . Si intenta ejecutarlo desde la raíz del proyecto con un comando como mvn org.example:foo-maven-plugin:generate-foo , no se ejecutará en los módulos agregados (consulte la nota de compatibilidad ).

Varias soluciones son posibles:

Implementar el complemento a la Central de Maven (no siempre es posible).
Especifique la sección del repositorio en todos sus POM agregados (se rompe el principio DRY ).
Tenga este repositorio interno configurado en la configuración.xml (ya sea en la configuración local en ~ / .m2 / configuración.xml o en la configuración global en /conf/settings.xml). Hará que la construcción falle sin esas configuraciones.xml (podría estar bien para grandes proyectos internos que nunca se deben construir fuera de la empresa).
Use la configuración de los padres con los repositorios en sus POM agregados (¿podrían ser demasiados POM de los padres?).