Расположение репозитория для крупных проектов Maven

У меня есть большое приложение (~ 50 модулей), используя структуру, похожую на следующее:

Применение
- Коммуникационные модули
  - Модуль цветной связи
  - Модуль связи SSN
  - и т.д.. коммуникационный модуль
- Модуль маршрутизатора
- Сервисные модули
  - Модуль обслуживания голосования
    - Субмодуль веб-интерфейса для голосования
    - Подмодуль голосового коллектора для голосования
    - и т.д.. для голосования
  - Сервисный модуль Quiz
  - и т.д.. модуль

Я хотел бы импортировать приложение в Maven и Subversion. После некоторых исследований я обнаружил, что для этого существуют два практических подхода.

Один использует древовидную структуру, как и предыдущую. Недостатком этой структуры является то, что вам нужна тонна tweaking/hacks, чтобы получить многомодульную отчетность с Maven. Другим недостатком является то, что в Subversion стандартный подход trunk/tags/branches добавляет еще большую сложность в репозиторий.

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

Какой путь вы бы выбрали в долгосрочной перспективе и почему?

Ответ 1

У нас есть довольно большое приложение (160+ пакетов OSGi, где каждый комплект является модулем Maven), и урок, который мы узнали, и продолжаем учиться, заключается в том, что квартира лучше. Проблема с семантикой кодирования в вашей иерархии заключается в том, что вы теряете гибкость. Модуль, который на 100% говорит "сообщение" сегодня, может быть частично "сервисом" завтра, а затем вам нужно будет перемещать вещи в своем репозитории, и это разрушит всевозможные скрипты, документацию, ссылки и т.д.

Поэтому я бы рекомендовал плоскую структуру и кодировать семантику в другом месте (например, рабочую область или документацию IDE).

Я несколько раз ответил на вопрос о макете управления версиями с примерами по другому вопросу, это может иметь отношение к вашей ситуации.

Ответ 2

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

Предполагая, что вы используете Eclipse в качестве своей IDE, все проекты в конечном итоге окажутся в плоском списке, как только вы их импортируете, так что вы действительно ничего не получаете от дополнительных вспомогательных каталогов. Это в дополнение к тому, что конфигурация настолько проста, что без дополнительной иерархии выбор становится ясным в моем сознании.

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