Repository макет для крупных проектов Maven

голоса
13

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

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

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

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

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

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

Задан 21/08/2008 в 15:06
источник пользователем
На других языках...                            


2 ответов

голоса
14

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

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

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

Ответил 21/08/2008 в 19:07
источник пользователем

голоса
3

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

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

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

Ответил 21/08/2008 в 19:06
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more