Управление зависимостями (Dependency Management)
в первую очередь следует обратить внимание на стандратную
документацию Maven. она довольпо подробно объясняет, как использовать механизм управления зависимостями. я хочу оставновится на некоторых моментах, которые могут быть не ясны из стандартной документации
включение и исключение библиотек при объявлении зависимостей
управление зависимости в Maven организованно довольно грамотно. оно учитывает все зависимости явно и не явно указанные в проекте и самостоятельно разрешает коллизи конфликта версий библиотек в пользу
указанных явно. так, если какая-то из подключенных библиотек, в свою очередь использует библиотеку, которая уже указана в зависимостях для проекта, то в данном случае будет использована библиотека,
указанная в зависимостях проекта. в данном случае безусловным приоритетом обладает явная декларация, что следует учитывать в случае возникновения конфликтов версий.
что касается практики организации зависимостей, то тут необходимо отметить два момента
- при огранизации зависимостей разрабатываемого модуля или приложения от сторонних библиотек, необходимо помнить, что все зависимости, для которых указан scope compile или не указан scope, будут автоматически включены в зависимости модуля, который использует разрабатываемый модуль. или, более простыми словами, если ваш модуль будет использован в дальнейшей разработки, все зависимости scope compile, автоматически окажутся в вашем локально репозитории и директории lib для war и ear. в случае, когда в таком поведении системы нет строгой необходимости использование тега optional более чем желательно.
в противном случае все пользователи вашего модуля будут получать на выходе гиганские объемы библиотек, которые они не используют. или же будут прибегать к практике из пункта 2
- при использовании сторонних библиотек следует обязательно обратить внимание на количество зависимостей, не отмеченных как optional, у используемого модуля. ярким примером являются релизы Spring весии 2.x, каждый модуль которого норовит вытащить из репозитория 90% фреймворка.
для того, чтобы избежать такого поведения той или иной библиотеки из зависимостей, необходимо отключить все не нужные в приложении зависимости, не объявленные в pom библиотеки, как optional.
в своей практике я часто оключал все зависимости подключенных библиотек, и включал явно только те, которые мне были нужны. однако, не могу сказать, что это оптимальный способ. скорее наоборот. с другой стороны этот способ дает полный и очевидный контроль над всеми без исключения зависимостями проекта, но pom файлы бывают очень большими и единоразовое их составление занимает довольно приличное время.
dependencyManagement vs dependencies. в чем разница?
разница между этими двумя секциями может быть сравнима с разницей между h и cpp файлами С++. dependencyManagement содержит
декларацию зависимостей, а dependencies -- зависимости, которые
непосредственно используются в проекте. в случае одномодульного проекта эта конструкция избыточна, однако для многомодульных проектов ее ценность тем выше, чем больше модулей составляют проект.
определить зависимости той или иной библиотеки можно окрыв ее pom файл внутри репозитория или используя
специальный ресурсуправление зависмостями в multimodule projects
для многомодульных проектов сложно переоценить значение секции dependencyManagement. ее использование позволяет объявить, а следовательно и
управлять, зависимости в
в одном единственном месте включая все необхоимые значения scope, exclusions и optional. этим местом является parent pom файл всего проекта. в pom файле каждого из модулей, в секции dependencies достаточно указать groupId и artifactId кокретной зависимости или плагина. Maven
автоматически использует остальные параметры аналогичной зависимости
из parent pom файла
разница между pluginManagement и plugins аналогична, равно как и аналогична их избыточность, важность и использование для разных проектов.
