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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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