Найкращий спосіб структурувати сховище Git для Maven

Мені потрібні поради, як структурувати наші проекти в Git. Ми використовуємо Java і Maven - це наш інструмент побудови. Maven свого роду припускає, що всі ваші проекти з часом мають спільного предка. Мейвен також може бути справжньою королевою драми, коли все налаштовано не так, як фонд Apache створює свої проекти (кожен, хто використовує плагін випуску, напевно, знає, про що я говорю).

Ми хочемо, щоб батьківський модуль верхнього рівня контролював версії плагінів і конфігурацію збирання (репо-конфігурація, які артефакти будувати, іменування конвенцій, версії плагінів тощо). Maven хотів би, щоб усі наші ІТ-проекти були у папках цього головного проекту. Це означає одне масштабне репо від Git для організації.

Це створить дуже шумні умови. Якщо є дві команди, які працюють над спорідненими проектами, їм постійно доведеться витягувати злиття від іншої команди. В ідеалі я хотів би мати одне репо на проект.

Але така сутичка з надзвичайно ієрархічною моделлю Maven, яка вимагає, щоб підпроекти були підпапками.

Мені потрібна порада, як люди примирили ці дві моделі ... дякую!

У вас є 2 варіанти:
1. за допомогою git способу: використовувати підмодулі. Ось документація про те, як git управляє підмодулями git submodules . Я особисто не використовував це, але, схоже, відповідає вашій проблемі.
2. Мавенським способом: у maven не обов'язково ваш кореневий проект (конфігурація) бути ієрархічно батьківським каталогом усіх ваших проектів. Ви можете мати таку структуру:

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)

конфігурація, project1 та project2 знаходяться на одному рівні каталогів, і кожен може бути сховищем git. Коли збираєте project1 або project2, ви запускаєте команду maven на рівні project1 або project2, і maven намагатиметься отримати батьківський (конфігурацію) з сховища maven, а не з батьківського каталогу. Слід звернути увагу на версії. Я б рекомендував у project1 або project2 зберігати посилання на батьків (конфігурацію) з версією випуску. Щоб зробити реліз, вам потрібно зробити це в два етапи: спочатку випустіть конфігурацію та випустіть проект другий. Project1 і project2 можуть еволюціонувати самостійно і не повинні мати ту саму версію конфігурації, що і батьківська.

Тільки для особливих випадків, коли ви хочете мати конфігурацію та проекти як версії SNAPSHOT, у project1 або project2 ви можете використовувати <relativePath>тег всередині<parent> тегу, щоб вказати на ваш локальний шлях конфігурації. Я не рекомендую цього, тому що створить проблеми в середовищі розробки (принаймні для мене в Eclipse)

Прошу вибачення за свою англійську.

Maven хотів би, щоб усі наші ІТ-проекти були у папках цього головного проекту

Ні, Мевен просто хоче вміти знайти артефакти, які їй потрібні. Найкращий спосіб зробити це зі сховищем артефактів, наприклад Nexus або Artifactory . Кожен проект може мати власне сховище Git.

Ми хочемо, щоб батьківський пам’ят верхнього рівня контролював версії плагінів та конфігурацію побудови (репо-конфігурація, які артефакти будувати , іменні конвенції, версії плагінів тощо)

Там ваша реальна проблема. Має сенс використовувати батьківський POM для забезпечення конфігурації, але немає ніяких причин поєднувати конфігурацію з керуванням управління. Насправді, окрім окремого мультимодульного проекту, я б сказав, що це надзвичайно погана ідея з тих самих причин, які ви заявляєте (плюс той факт, що вам доведеться будувати всі ваші проекти, усі час).