В проекте Maven, каковы причины для вложенного или плоского макета каталога? - PullRequest
Новая
       12

В проекте Maven, каковы причины для вложенного или плоского макета каталога?

3 голосов
/ 21 мая 2010

По мере роста моего проекта Maven я стараюсь оставаться на вершине структуры проекта. Пока у меня есть вложенная структура каталогов с 2-3 уровнями, где на каждом уровне есть POM с module записями, соответствующими каталогам на этом уровне. Наследование POM (parent свойство) не обязательно следует за этим и не имеет отношения к цели этого вопроса.

Теперь, когда вложенная структура кажется довольно естественной для Maven, и она хороша и чиста, пока вы находитесь на одном конкретном уровне, я начинаю путаться из-за того, что смотрю в своей IDE (Eclipse и IntelliJ IDEA ).

Я посмотрел на исходники Apache Felix, и у них довольно сложный проект, который выглядит как плоская структура каталогов, поэтому мне интересно, будет ли это лучший путь?

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

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

Ответы [ 2 ]

1 голос
/ 21 мая 2010

Я использую своего рода смешанный подход.Вещи с различным жизненным циклом (с точки зрения выпуска и, следовательно, VCS) плоские, вещи с одинаковым жизненным циклом вложены.И я использую svn:externals для проверки.Я написал об этом подходе в этом предыдущем ответе .

1 голос
/ 21 мая 2010

Я голосую за вложение. Я использую IDEA 9, которая показывает вложение на панели проекта, поэтому презентация отражает вашу логическую структуру проекта. (Это было не так в 8.1 - это было выровнено.)

Я предпочитаю хранить вещи вложенными, особенно если имена очень похожи - значительно упрощает навигацию при использовании командной строки. У меня есть проект с такими именами, как myapp-layer-component, поэтому все они начинаются с одного и того же префикса, и многие имеют одинаковый -layer-, поэтому использование автозаполнения в командной строке практически бесполезно. Разделить их на вложенную структуру будет намного проще, потому что каждая часть имени (имя приложения, слой или компонент) повторяется только один раз на каждом уровне в структуре каталога.

При сборке из командной строки гораздо проще создать подмножество проекта, например, если я работаю над моделью БД, то часто мне нужно строить все проекты в этой области. Это сложно сделать, когда файлы выровнены - единственный известный мне способ - использовать аргумент -pl для maven и указать проекты для сборки. С вложенными каталогами я просто cd в каталог db и запускаю mvn.

Например, вместо 

myapp-web-gui1
myapp-web-gui2
myapp-web-base
myapp-svc-clustered
myapp-svc-clustered-integrationtest
myapp-svc-simple
myapp-db-model
myapp-db-hibernate

У нас есть структура 

\myapp
   \web
     \gui1
        pom.xml
     \gui2
        pom.xml  (other poms omitted to keep it short)
     \base
   \svc
      \clustered
      \clustered-it
      \simple
   \db
      \model
      \hibernate

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

С помощью вложенности вы также получаете все преимущества наследования (и некоторые из его трудностей ...)

Единственная проблема, с которой я столкнулся, заключается в том, что имя каталога не соответствует идентификатору артефакта. (Я все еще использую полные artifactIds.) И поэтому каждый проект должен явно определять пути SCM, поскольку они больше не могут быть выведены из родительского pom. Конечно, каждый каталог может быть сделан так же, как artifactId, и тогда детали SCM могут быть выведены из родительского, но я нашел длинные имена каталогов немного громоздкими.

...