Как работает файловая структура maven? - PullRequest
1 голос
/ 27 января 2010

Мы планируем реструктурировать сложный проект с множеством модулей / частей, как бы вы это ни называли. Чтобы перейти к стандартной структуре каталогов, мы хотели бы принять файловую структуру maven.

Итак, большой вопрос: кто-нибудь может дать описание структуры файла maven, где нам не нужно копаться во всех разговорах maven?

Ответы [ 2 ]

5 голосов
/ 27 января 2010

Пожалуйста, смотрите http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

src/main/java      Application/Library sources
src/main/resources   Application/Library resources
src/main/filters    Resource filter files
src/main/assembly    Assembly descriptors
src/main/config      Configuration files
src/main/webapp      Web application sources
src/test/java      Test sources
src/test/resources   Test resources
src/test/filters     Test resource filter files
src/site            Site
LICENSE.txt          Project's license
README.txt        Project's readme

Кстати, мы осуществили эту миграцию на существующих проектах. Было очень долгой и трудной задачей заставить все работать как задумано, но мы наконец-то сделали это и довольны.


ОБНОВЛЕНО

Когда у вас много проектов, у вас есть одинаковая структура для каждого проекта .

Теперь настоящая проблема начинается, когда вы хотите сгруппировать их. Нам было трудно читать документацию и лучшие практики Maven и решать, какая структура нам подходит.

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

Мы получили строгую иерархию, которая избавила нас от многих трудностей:

  • Фактические проекты кодирования (проекты Java) всегда находятся в нашем дереве каталогов. Они единственные, которые мы открываем в IDE. Они относятся к типу JAR или WAR.
  • Их родители / модули всегда имеют тип POM. У них нет кода Java.
0 голосов
/ 11 марта 2010

Я использовал тот же подход, что и Дженс, в ряде проектов как с Maven 2.2.1, так и с Maven 3.0-alpha-6: модули POM определяют структуру модулей вашего дерева проектов, модули JAR / WAR листья дерева. Все модули имеют одинаковую версию.

Преимущества:

  • Вы можете разместить свойства или зависимости от конкретные уровни в модуле иерархия и они будут унаследованы для всех подмодулей.
  • Вы можете построить связанные модули просто перейдя на соответствующий уровень в дереве и работает "mvn install" - Maven будет отработать правильный порядок сборки согласно.
  • Различные плагины Maven такие как релиз плагин полагаться на это древовидная структура
  • Последний Maven Eclipse плагин может справиться с этим структура очень хорошо и будет представлять дерево в виде плоского списка. Есть экспериментальная особенность в плагин, который гарантирует, что появляются так называемые "затененные" артефакты только один раз, который помогает при поиске для ресурсов в Eclipse.

Недостатки:

  • Расширение занимает некоторое время. Например, если вы решите, что для модуля JAR требуются субмодули, вам нужно будет преобразовать существующий модуль JAR в модуль POM, а затем распространить его содержимое во вновь созданные субмодули JAR, поскольку модули POM сами по себе не могут содержать никакого кода.
  • Все модули POM появятся в Eclipse и могут несколько замедлить сборку. Однако вы можете закрыть их, и вместо этого Eclipse будет получать их из хранилища.
...