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

Question

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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