Какая информация содержится в pom.xml
Что проверяют
Понимаете ли вы Maven как модель проекта, а не как список зависимостей, скопированный из интернета. Следом почти всегда спрашивают, чем dependencies отличается от dependencyManagement и как Maven решает конфликт версий.
Как отвечать
Разложите содержимое по назначению:
- координаты:
groupId,artifactId,versionиpackaging(по умолчаниюjar).modelVersionдля Maven 3 всегда4.0.0; parent: наследование настроек, например отspring-boot-starter-parent. Всё, что не указано, приходит из родителя, а в самом верху из суперпома Maven;properties: версии и параметры сборки, напримерmaven.compiler.releaseиproject.build.sourceEncoding;dependencies: зависимости соscope. По умолчаниюcompile, ещё естьprovided,runtime,test,systemиimport;dependencyManagement: только фиксирует версии, не подключая зависимостей. Сюда же импортируют BOM через<type>pom</type>и<scope>import</scope>;build: плагины и их настройки (maven-compiler-plugin,maven-surefire-plugin,spring-boot-maven-plugin), аpluginManagementделает для плагинов то же, чтоdependencyManagementдля зависимостей;modules: список модулей в многомодульном проекте;profiles: наборы настроек под окружение или условие.
Отдельно скажите про конфликты: при разных версиях одной библиотеки в дереве побеждает ближайшая к проекту, а при равной глубине объявленная первой. Смотрят это через mvn dependency:tree, лечат через exclusions или явную версию в dependencyManagement. Итоговую модель со всеми унаследованными значениями показывает mvn help:effective-pom.
Где спотыкаются
Не различают dependencies и dependencyManagement и удивляются, почему библиотека из второго блока не попала в classpath.
Кладут пароли и адреса внутренних репозиториев с учётными данными в pom.xml. Им место в settings.xml, а pom лежит в git и виден всем.
Забывают про scope. Тестовая библиотека без test попадает в основной classpath и в итоговый fat jar или war, а зависимость контейнера без provided дублирует то, что уже есть на сервере.