Versiones del código fuente en Maven Parent POM

Administro un proyecto Maven POM, que (como es habitual en los proyectos POM) consta de 1 file: pom.xml . Hay muchos otros proyectos que henetworkingan configuraciones de este POM. El padre pom no funciona como un agregador; no hay modules definidos en él.

Como el proyecto POM tiene un ciclo de versiones y un historial de versiones diferentes a los proyectos que dependen de él, me parece lógico ubicarlo en un repository de SCM separado. La idea es que se genere un trabajo de compilation automatizado en un compromiso, que luego puede conducir a un lanzamiento del nuevo POM al repository de artefactos central (Nexus). Esto lleva a la situación en la que tengo un repository de Git con 1 file.

Pregunta : ¿Es esta la forma normal / deseada de manejar versiones de código fuente de un proyecto POM?

Un pom padre común (o empresarial) común debe considerarse como un producto separado, es un artefacto en sí mismo, con su propio ciclo de vida y trabajo de CI (publicarlo en un repository de Maven, como Nexus en su caso) y, como tal, también con su propio repository de control de versiones.

Además, tampoco puede ser un repository con un solo file, el file esencial pom.xml , sino que también proporciona más resources. Por ejemplo, una carpeta de site , con su file site.xml que especifica un informe o sección adicional. En el caso de un repository de git, también debe proporcionar un file README.md bien documentado.


Por experiencia, dado que un POM padre Maven global es utilizado por muchos proyectos diferentes, también es bueno cuidar sus versiones y notas de lanzamiento. Por estas razones, sugeriría tener lo siguiente:

  • Una carpeta de site con la siguiente configuration site.xml (como ejemplo):
     <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/DECORATION/1.4.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/DECORATION/1.4.0 http://maven.apache.org/xsd/decoration-1.4.0.xsd"> <body> <menu ref="reports" /> <menu name="Release Notes"> <item name="0.0.1" href="release-notes-0.0.1.html" /> </menu> </body> </project> 
  • Una carpeta adicional de markdown en el site proporciona notas de la versión para cada versión. Por ejemplo, desde el href arriba, se recogerá el siguiente file: release-notes-0.0.1.md.vm , que proporciona información sobre su lanzamiento, que luego terminará en el sitio de Maven del POM.

Como puede ver, el repository puede contener más que el único file pom.xml incluso para un POM súper parental. Por lo tanto, siempre debe tener su propio repository de control de versiones (git en este caso).


Notas adicionales:

  • Un POM principal global normalmente aplica el sufijo -parent (p. Ej., maven-parent , spring-parent , hibernate-parent ). Aunque no es un estándar, es una convención de hecho, se recomienda seguir
  • Preferiblemente, siga el layout oficial de Maven para las secciones de POM
  • Por experiencia personal, evite tener versiones de SNAPSHOT : mejor tener múltiples versiones menores (pero fijas) de un POM padre común en lugar de versiones inestables o potencialmente impactantes de SNAPSHOT : es el pom padre global, su objective es proporcionar un gobierno y una configuration mínima común, no debe introducir inestabilidad.