Советы по созданию структуры проекта Maven - несколько модулей против нескольких проектов? - PullRequest
6 голосов
/ 10 февраля 2012

Рассмотрим следующий пример многоуровневой обработки корпоративных приложений:

  1. project-services -> Уровень POJO Services
  2. project-web -> веб-приложение, зависит от 'project-services', развернуто как WAR
  3. project-web-services -> веб-службы, зависит от «project-services», развернутых как отдельная WAR, которые в настоящее время не предоставляются через Интернет
  4. project-standalone -> Cron Jobs, зависит от 'project-services'

Что было бы правильным подходом для организации этого в Maven. Должен ли я создать мультимодульный проект Maven? если 'project-services' - это модуль Maven, можно ли использовать его совместно с тремя другими проектами, каждый из которых является независимым развертываемым модулем?

В моих предыдущих проектах я просто создал 4 различных проекта Maven и никогда не чувствовал особой нужды.

Хотите проверить, есть ли лучший способ, чем я делал ранее.

Ответы [ 4 ]

2 голосов
/ 10 февраля 2012

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

pom project (top level project that would define all of the modules)
  jar project (project-services)
  war project (project-web)
  war project (project-web-services)
  project-standalone (wasn't sure if this was a jar, or just some scripts, etc)

Таким образом, вы только собираете и выпускаете корневой проект, и он позаботится обо всех субмодулях.Каждый из них может иметь зависимости друг от друга (просто будьте осторожны с круговыми зависимостями).И вы в значительной степени готовы к работе.

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

И, очевидно, вы можете иметь микс, так что, возможно, фляга автономна, но у вас естьмногомодульный проект, который содержит два военных файла.Преимущество maven заключается в том, что он достаточно гибок, чтобы справляться с любыми имеющимися у вас бизнес-кейсами, чтобы разделить их.

1 голос
/ 11 февраля 2012

На моем рабочем месте у нас много проектов верхнего уровня, которые совместно используют библиотеки (15 проектов верхнего уровня совместно используют около 35 библиотек). Мы использовали единый проект для каждой библиотеки. Сегодня, когда мы должны выпустить их всех за один раз, это просто кошмар.

Некоторые проблемы, с которыми мы сталкиваемся:

  • Вручную выяснить зависимости
  • Необходимо запустить релиз в правильном порядке
  • Один сбой останавливает весь выпуск

Если бы мне пришлось все повторить (я помогал все это настроить), я бы использовал один многомодульный проект. Если ничто иное, выпуск всего за один раз - огромное преимущество. Проекты могут выглядеть не очень хорошо в затмении, но это не то, к чему вы должны стремиться в любом случае.

0 голосов
/ 15 февраля 2012

Поскольку у вас есть прямые зависимости между модулями, я бы также порекомендовал их для многомодульного проекта.

Что я часто рекомендую, так это рассмотреть жизненный цикл модулей. Например: если вы выпускаете пакетный модуль гораздо чаще, чем уровень обслуживания, возможно, имеет смысл разделить его на части. Таким образом, вам не нужно выпускать (развертывать) вещи, которые не были изменены. Поскольку пакет обычно не развертывается так же, как файлы .war. Но это зависит от жизненного цикла сервисных + пакетных модулей.

В большинстве случаев двигаться бок о бок. Так что +1 за «один за всех»

0 голосов
/ 10 февраля 2012

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

Имея в качестве корня POM-проект и разделяя все реализации и другие артефакты, это обычно считается хорошей практикой для всего, кроме одномодовых проектов.

...