La mejor manera de estructurar un repositorio Git para Maven

Necesito algunos consejos sobre cómo estructurar nuestros proyectos en Git. Utilizamos Java y Maven es nuestra herramienta de compilación. Maven asume que todos tus proyectos tienen un antepasado común eventualmente. Maven también puede ser una verdadera reina del drama cuando las cosas no están configuradas exactamente de la manera en que la fundación Apache configura sus proyectos (cualquiera que use el complemento de lanzamiento probablemente sepa de lo que estoy hablando).

Queremos un pom padre de nivel superior que controle las versiones de complementos y la configuración de compilación (configuración de repositorio, qué artefactos construir, convenciones de nombres, versiones de complementos, etc.). Maven querría que todos nuestros proyectos de TI estén en subcarpetas de ese proyecto principal. Esto implica un repositorio masivo de Git para la organización.

Esto creará un ambiente muy ruidoso. Si hay dos equipos trabajando en proyectos no relacionados, tendrán que incorporar constantemente las fusiones del otro equipo. Idealmente, me gustaría tener un repositorio por proyecto.

Pero ese tipo de enfrentamientos con el modelo extremadamente jerárquico de Maven, que exige que los subproyectos sean subcarpetas.

Necesito algunos consejos sobre cómo la gente ha reconciliado estos dos modelos ... ¡gracias!

Tienes 2 opciones:
1. por git: usa submódulos. Aquí hay una documentación sobre cómo git administra los submódulos git submodules . Yo personalmente no lo usé, pero parece ajustarse a su problema.
2. por medio de maven: en maven no es obligatorio que su proyecto raíz (configuración) sea jerárquicamente el directorio principal de todos sus proyectos. Puedes tener una estructura como esa:

configuration
 +-- pom.xml (configuration:XXX)
project1
 +-- pom.xml (project1:1.0-SNAPSHOT)
 !
 +-- module11 
 !     +-- pom.xml (1.0-SNAPSHOT)
 +-- module12
       +-- pom.xml (1.0-SNAPSHOT)
project2
 +-- pom.xml (project2:2.0-SNAPSHOT)
 !
 +-- module21 
 !     +-- pom.xml (2.0-SNAPSHOT)
 +-- module22
       +-- pom.xml (2.0-SNAPSHOT)

configuration, project1 y project2 están en el mismo nivel de directorio y cada uno podría ser un repositorio git. Al compilar project1 o project2, ejecuta el comando maven desde el nivel project1 o project2 y maven intentará obtener el padre (configuración) del repositorio maven no del directorio padre. Debes prestar atención a las versiones. Recomendaría en project1 o project2 mantener una referencia a un padre (configuración) con una versión de lanzamiento. Para realizar un lanzamiento, debe hacerlo en 2 pasos: primero, la configuración de lanzamiento y el proyecto de lanzamiento segundo. Project1 y project2 pueden evolucionar independientemente y no tiene que tener la misma versión de configuración que un padre.

Solo para casos especiales en los que desea tener tanto la configuración como los proyectos como versiones SNAPSHOT, en project1 o project2 puede usar la <relativePath>etiqueta inside <parent>tag para apuntar a su ruta local de configuración. No recomiendo esto porque creará problemas en el entorno de desarrollo (al menos para mí en Eclipse)

Me disculpo por mi Inglés.

Maven querría que todos nuestros proyectos de TI estén en subcarpetas de ese proyecto principal

No, Maven simplemente quiere poder recuperar los artefactos que necesita. La mejor manera de hacerlo es con un repositorio de artefactos, como Nexus o Artifactory . Cada proyecto puede tener su propio repositorio Git.

Queremos un pom padre de nivel superior que controle las versiones de complementos y la configuración de compilación (configuración de repositorio, qué artefactos construir , convenciones de nombres, versiones de complementos, etc.

Ahí está tu verdadero problema. Tiene sentido usar un POM principal para imponer la configuración, pero no hay razón para combinar la configuración con el control de compilación. De hecho, a excepción de un proyecto de módulos múltiples independiente, diría que es una idea extremadamente mala, solo por las razones que declaras (más el hecho de que tendrías que construir todos tus proyectos, todos el tiempo).