Parece que hay varias formas de estructurar los padres poms en una compilación multiproyecto y me pregunto si alguien tuvo alguna idea sobre cuáles son las ventajas / inconvenientes en cada sentido.
El método más simple de tener un pom padre sería ponerlo en la raíz de un proyecto, es decir
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xmldonde pom.xml es tanto el proyecto principal como describe los módulos -core -api y -app
El siguiente método es separar al padre en su propio subdirectorio como en
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/Donde el pom padre 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 el padre se separan como en
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xmlDonde el pom padre contiene cualquier configuración "compartida" (dependencyManagement, propiedades, etc.) y 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 debería ser escalable a una gran cantidad de proyectos y artefactos.
Algunas preguntas extra:
- ¿Dónde es el mejor lugar para definir las diversas configuraciones compartidas como en el control de origen, directorios de implementación, complementos comunes, etc. (Asumo que es el padre pero a menudo me ha mordido esto y terminaron en cada proyecto en lugar de uno común).
- ¿Cómo lidian el complemento de lanzamiento de Maven, Hudson y Nexus con la forma en que configuran sus proyectos múltiples (posiblemente una pregunta gigante, es más si alguien ha quedado atrapado cuando se ha configurado una construcción de proyectos múltiples)?
Editar: cada uno de los subproyectos tiene su propio pom.xml, lo dejé fuera para mantenerlo conciso.
fuente
Respuestas:
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 padre tiene su propio ciclo de vida, es decir, se puede liberar por separado de los otros módulos o no?
Si la respuesta es sí (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 padre pom 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 usarlo
svn:externals. Por ejemplo, agregue untrunksdirectorio:Con la siguiente definición externa:
Una comprobación de
trunksentonces daría como resultado la siguiente estructura local (patrón # 2):Opcionalmente, incluso puede agregar un
pom.xmlen eltrunksdirectorio:Este
pom.xmles un tipo de pom "falso": nunca se lanza, no contiene una versión real ya que este archivo nunca se lanza, solo contiene una lista de módulos. Con este archivo, un pago resultará en esta estructura (patrón # 3):Este "truco" permite lanzar una construcción de reactor desde la raíz después de un pago y hacer las cosas aún más útiles. En realidad, así es como me gusta configurar proyectos maven y un repositorio VCS para grandes construcciones : simplemente funciona, se escala 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 pueda funcionar).
Ahora, sobre las preguntas de bonificación:
Honestamente, no sé cómo no dar una respuesta general aquí (como "usa el nivel en el que crees que tiene sentido mutualizar las cosas"). Y de todos modos, los poms secundarios siempre pueden anular la configuración heredada.
La configuración que uso funciona bien, nada en particular que mencionar.
En realidad, me pregunto cómo el plugin maven-release-plugin trata con el patrón # 1 (especialmente con la
<parent>sección ya que no puede tener dependencias SNAPSHOT en el momento del lanzamiento). Esto suena como un problema de huevo o gallina, pero no puedo recordar si funciona y fue demasiado vago para probarlo.fuente
Según mi experiencia y las mejores prácticas de Maven, hay dos tipos de "padres poms"
pom padre de "empresa": este pom contiene la información y la configuración específicas de su empresa que heredan cada pom y no necesitan copiarse. Estas informaciones son:
La preparación de este pom padre debe hacerse con precaución, ya que todos los poms de su empresa heredarán de ella, por lo que este pom debe ser maduro y estable (¡liberar una versión de pom padre no debería afectar para liberar todos los proyectos de su empresa!)
Los multiproyectos tienen una estructura de árboles, por lo que no estás reducido a un solo nivel de padre pom. Intente encontrar una estructura de proyecto adecuada para sus necesidades: un ejemplo clásico es cómo distribuir proyectos de módulos múltiples
Esta configuración debe dividirse sabiamente en un pom padre de "empresa" y pom padres del proyecto. Las cosas relacionadas con todo lo que proyecta van al padre de la "compañía" y esto está relacionado con el proyecto actual.
La empresa matriz pom debe ser lanzada primero. Para multiproyectos se aplican reglas estándar. El servidor de CI necesita saber todo para construir el proyecto correctamente.
fuente
Un padre independiente es la mejor práctica para compartir configuraciones y opciones a través de componentes que de otro modo no estarían acoplados. Apache tiene un proyecto pom padre para compartir avisos legales y algunas opciones comunes de empaque.
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 hacer ese trabajo y la configuración que desea compartir a través de los padres. Un proyecto solo para padres evita eso.
Un patrón común (ignorando el n. ° 1 por el momento) es hacer que los proyectos con código usen un proyecto padre como padre y que usen el nivel superior como padre. Esto permite que todos compartan las cosas principales, pero evita el problema descrito en el n. ° 2.
El complemento del sitio se confundirá mucho si la estructura principal no es la misma que la estructura del directorio. Si desea construir un sitio agregado, necesitará hacer algunos ajustes para evitar esto.
Apache CXF es un ejemplo del patrón en el n. ° 2.
fuente
Hay una pequeña trampa con el tercer enfoque. Dado que los POM agregados (myproject / pom.xml) generalmente no tienen padre en absoluto, no comparten la configuración. Eso significa que todos esos POM agregados solo tendrán repositorios predeterminados.
Eso no es un problema si solo usa complementos de Central, sin embargo, esto fallará si ejecuta el complemento usando el complemento: formato de objetivo desde su repositorio interno. Por ejemplo, puede tener
foo-maven-plugincon el groupId deorg.exampleproporcionar objetivogenerate-foo. Si intenta ejecutarlo desde la raíz del proyecto utilizando un comando comomvn org.example:foo-maven-plugin:generate-foo, no se ejecutará en los módulos agregados (consulte la nota de compatibilidad ).Son posibles varias soluciones:
fuente