Макет репозитория для больших проектов Maven

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

  • Application
    • Communication modules
      • Color communication module
      • Модуль связи SSN
      • и т. д. коммуникационный модуль
    • Модуль маршрутизатора
    • Service modules
      • Voting service module
        • Web interface submodule for voting
        • Подмодуль сборщика голосов для голосования
        • и т.д. для голосования
      • Модуль сервиса викторины
      • и т. д. модуль

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

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

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

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


java svn maven-2
person Zizzencs    schedule 21.08.2008    source источник

Ответы (2)


arrow_upward
15
arrow_downward

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

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

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

person Boris Terzic    schedule 21.08.2008

arrow_upward
3
arrow_downward

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

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

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

person Mike Deck    schedule 21.08.2008