Лучший способ структурировать Git-репозиторий для Maven


19

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

Нам нужен родительский pom верхнего уровня, который контролирует версии плагинов и конфигурацию сборки (конфигурацию репозитория, какие артефакты собирать, соглашения об именах, версии плагинов и т. Д.). Maven хотел бы, чтобы все наши ИТ-проекты были в подпапках этого основного проекта. Это подразумевает одно огромное Git-репо для организации.

Это создаст очень шумную обстановку. Если есть две команды, работающие над несвязанными проектами, им постоянно придется собирать слияния другой команды. В идеале я хотел бы иметь один репо на проект.

Но такого рода противоречия с крайне иерархической моделью Maven, которая требует, чтобы подпроекты были подпапками.

Мне нужен совет о том, как люди примирили эти две модели ... спасибо!


2
lwm

Ответы:


19

У вас есть 2 варианта:
1. git way: использовать субмодули. Вот документация, как git управляет подмодулями git submodules . Лично я не использовал это, но это выглядит, чтобы соответствовать вашей проблеме.
2. путем maven: в 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)

config, project1 и project2 находятся на одном уровне каталогов, и каждый из них может быть репозиторием git. При сборке project1 или project2 вы запускаете команду maven с уровня project1 или project2, и maven пытается извлечь родительский элемент (конфигурацию) из репозитория maven, а не из родительского каталога. Вы должны обратить внимание на версии. Я бы порекомендовал в project1 или project2 сохранить ссылку на родителя (конфигурацию) с версией выпуска. Чтобы сделать релиз, вы должны сделать это в 2 шага: сначала выпустить конфигурацию, а затем выпустить проект. Project1 и project2 могут развиваться независимо и не должны иметь одинаковую версию конфигурации с родительской.

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

Я извиняюсь за мой английский.


3

Maven хотел бы, чтобы все наши ИТ-проекты были в подпапках этого основного проекта.

Нет, Мэйвен просто хочет иметь возможность получать нужные артефакты. Лучший способ сделать это - использовать хранилище артефактов, такое как Nexus или Artifactory . Каждый проект может иметь свой собственный репозиторий Git.

Нам нужен родительский pom верхнего уровня, который контролирует версии плагинов и конфигурацию сборки (конфигурацию репозитория, какие артефакты собирать , соглашения об именах, версии плагинов и т. Д.

Вот твоя настоящая проблема. Имеет смысл использовать родительский POM для обеспечения конфигурации, но нет причин объединять конфигурацию с управлением сборкой. На самом деле, за исключением отдельного многомодульного проекта, я бы сказал, что это очень плохая идея, по причинам, которые вы заявляете (плюс тот факт, что вам придется строить все свои проекты, все время).


Я хорошо знаком с тем, как работает Maven. И нет, я не хочу, чтобы мои команды строили всю кодовую базу. Обычно вы выбираете небольшое количество проектов и выводите их из-под контроля исходного кода. У нас есть сервер Nexus для размещения готовых артефактов, поэтому нет причин создавать всю кодовую базу. И как только ваша организация достигнет определенного размера, использование общей инфраструктуры экономит деньги. Наличие центральной конфигурации для этого - единственный способ убедиться, что он работает каждый раз.
Джонатан С. Фишер

Уважаемый @parsifal, пожалуйста, взгляните на мой вопрос о создании многослойного приложения java stackoverflow.com/questions/49562268/…
Хосейн Акаджани
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.