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

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

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

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

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

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

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

21.08.2008 14:06:44
2 ОТВЕТА
РЕШЕНИЕ

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

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

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

15
23.05.2017 12:33:27

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

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

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

3
21.08.2008 18:06:52