Родительский англичанин знатока по сравнению с англичанином модулей
Кажется, существует несколько способов структурировать родительских англичан в многопроектной сборке и мне задающийся вопросом, были ли у кого-либо какие-либо мысли о том, что преимущества / недостатки находятся каждым способом.
Самый простой метод наличия родительского англичанина поместил бы его в корень проекта т.е.
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
где pom.xml является и родительским проектом, а также описывает - ядро - API и - модули приложения
Следующий метод должен выделить родителя в свой собственный подкаталог как в
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
Где родительский англичанин все еще содержит модули, но они относительны, например../myproject-core
Наконец, существует опция, где определение модуля и родитель разделяются как в
myproject/
mypoject-parent/
pom.xml
myproject-core/
myproject-api/
myproject-app/
pom.xml
Где родительский англичанин содержит любую "общую" конфигурацию (dependencyManagement, свойства и т.д.), и myproject/pom.xml содержит список модулей.
Намерение состоит в том, чтобы быть масштабируемым к крупномасштабной сборке, так должно быть масштабируемым к большому количеству проектов и артефактов.
Несколько вопросов о премии:
- Где лучшее место должно определить различную общую конфигурацию как в управлении исходным кодом, каталогах развертывания, общие плагины и т.д. (Я принимаю родителя, но я часто кусался этим, и они закончили в каждом проекте, а не общем).
- Как делают плагин выпуска знатока, Гудзон и связь имеют дело с тем, как Вы настраиваете свои мультипроекты (возможно гигантский вопрос, это больше, если кто-либо ловился, когда тем, как многопроектная сборка была настроена)?
Править: Каждый из подпроектов имеет их собственный pom.xml, я пропустил его для хранения его кратким.
3 ответа
На мой взгляд, чтобы ответить на этот вопрос, нужно подумать о жизненном цикле проекта и контроле над версиями. Другими словами, имеет ли родительский pom собственный жизненный цикл, т.е. может ли он быть выпущен отдельно от других модулей или нет?
Если ответ да (а это касается большинства проектов, которые были упомянуты в вопросе или в комментариях), то родительскому pom нужен свой собственный модуль с ВКС и с точки зрения Maven, и в итоге вы получите нечто подобное на уровне ВКС:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
`-- projectA
|-- branches
|-- tags
`-- trunk
|-- module1
| `-- pom.xml
|-- moduleN
| `-- pom.xml
`-- pom.xml
Это делает проверку немного болезненной и обычным способом борьбы с этим - использовать svn:externals. Например, добавьте каталог trunks:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
Со следующим определением externals:
parent-pom http://host/svn/parent-pom/trunk
projectA http://host/svn/projectA/trunk
Оформление trunks приведет к следующей локальной структуре (образец №2):
root/
parent-pom/
pom.xml
projectA/
Опционально, вы даже можете добавить pom. xml в каталоге trunks:
root
|-- parent-pom
| |-- branches
| |-- tags
| `-- trunk
| `-- pom.xml
|-- projectA
| |-- branches
| |-- tags
| `-- trunk
| |-- module1
| | `-- pom.xml
| |-- moduleN
| | `-- pom.xml
| `-- pom.xml
`-- trunks
`-- pom.xml
Этот pom.xml - своего рода "поддельный" pom: он никогда не выпускался, он не содержит реальной версии, так как этот файл никогда не выпускался, он содержит только список модулей. При использовании этого файла, проверка приведет к такой структуре (шаблон #3):
root/
parent-pom/
pom.xml
projectA/
pom.xml
Этот "взлом" позволяет запускать сборку реактора с корня после проверки и делает вещи еще более удобными. На самом деле, именно так я люблю настраивать maven проекты и VCS репозиторий для больших сборок: это просто работает, это хорошо масштабируется, это даёт всю необходимую гибкость.
Если ответ нет (вернёмся к начальному вопросу), то я думаю, что вы можете жить с шаблоном #1 (сделайте самую простую вещь, которая может сработать).
Теперь о бонусных вопросах:
- Где лучшее место для определения различных общих конфигураций, как в управлении исходными текстами, каталогах развёртывания, общих плагинах и т.д. (Я предполагаю родителя, но меня часто укусывало это, и они заканчивались в каждом проекте, а не в общем)
Честно говоря, я не знаю, как не дать общий ответ здесь (например, "используйте уровень, на котором, по вашему мнению, имеет смысл взаимно дополнять вещи"). И в любом случае, дочерние помпы всегда могут переопределить унаследованные настройки.
- Как плагин maven-release, hudson и nexus справляются с тем, как вы настраиваете свои мультипроекты (возможно, это гигантский вопрос, больше, если кто-то попался, когда по тому, как настраивается сборка мультипроекта)?
Настройка, которую я использую, работает хорошо, не говоря уже о чем-то особенном.
На самом деле, мне интересно, как maven-release-plugin работает с паттерном #1 (особенно с разделом
По моему опыту и лучшей практике Maven существует два вида "родительских пом"
"компании" - этот пом содержит специфическую информацию и конфигурацию вашей компании, которая наследует каждый пом и не нуждается в копировании. Эта информация:
- repositories
- deficiment sections
- common plugins configurations (такие как maven-compiler-plugin source и target versions)
- organization, developers, etc
Подготовка этого родительского pom'а должна быть сделана с осторожностью, потому что все pom'ы вашей компании унаследуют от него, так что этот pom должен быть зрелым и стабильным (выпуск версии родительского pom'а не должен повлиять на выпуск всех ваших проектов компании! )
- второй вид родительского pom является многомодульным. Я предпочитаю ваше первое решение - это соглашение по умолчанию maven для многомодульных проектов, очень часто представляет собой структуру кода VCS
Цель - быть масштабируемой к крупномасштабной сборке, поэтому должна быть масштабируемой к большому количеству проектов и артефактов.
Мутли-проекты имеют структуру деревьев - поэтому вы не стрелка вниз до одного уровня родительского помпа. Попробуйте найти подходящую для ваших нужд структуру проекта - классический образец - как перепрограммировать проекты мутимодулей
distibution/
documentation/
myproject/
myproject-core/
myproject-api/
myproject-app/
pom.xml
pom.xml
Несколько бонусных вопросов:
- Где лучше всего определить различные общие конфигурации, как в управлении исходниками, каталогах развёртывания, общих плагинах и т.д. (я предполагаю, что это родительский pom, но меня это часто кусало, и они заканчивались в каждом проекте, а не в общем).
Эта конфигурация должна быть разумно разделена на родительские pom(ы) "компании" и родительские pom(ы) проекта. Все, что связано с вашим проектом, попадает в родительский pom "company", а все, что связано с текущим проектом, - в родительский pom(ы) проекта.
- Как плагин maven-release, hudson и nexus справляются с тем, как вы настраиваете свои мультипроекты (возможно, это гигантский вопрос, больше, если кто-то был пойман, когда по тому, как была настраивается сборка мультипроекта)?
Родительский pom компании должен быть выпущен первым. Для мультипроектов применяются стандартные правила. Для правильной сборки проекта CI сервер должен знать все.
Независимый родитель - это лучшая практика для обмена конфигурацией и опциями между другими несвязанными компонентами. В Apache есть родительский проект pom для совместного использования законных уведомлений и некоторых общих опций упаковки.
Если в вашем проекте верхнего уровня есть реальная работа, такая как объединение javadoc или упаковка релиза, то у вас будут конфликты между настройками, необходимыми для этой работы и настройками, которые вы хотите разделить через родителя. Родительский проект избегает этого.
Общий шаблон (игнорируя #1 на данный момент) состоит в том, что проекты с кодом используют родительский проект в качестве родительского, а верхний уровень - в качестве родительского. Это позволяет разделить основные вещи между всеми, но позволяет избежать проблемы, описанной в #2.
Плагин сайта будет очень запутанным, если родительская структура не совпадает со структурой каталога. Если вы хотите собрать общий сайт, вам нужно будет немного пошалить, чтобы обойти это.
Apache CXF - это пример шаблона в #2.