1. Проблема и варианты
Maven — очень универсальный инструмент, и его доступные публичные репозитории не имеют себе равных. Однако всегда будет артефакт, который либо не размещен где-либо , либо хранилище, в котором он размещен, рискованно зависеть, так как он может не работать, когда он вам нужен. Когда это происходит, есть несколько вариантов:
- Укуси пулю и установи полноценное решение для управления хранилищем, такое как Nexus
- попытаться загрузить артефакт в один из более авторитетных общедоступных репозиториев
- установить артефакт локально с помощью плагина maven
Nexus, конечно, более зрелое решение, но оно также и более сложное . Предоставление экземпляра для запуска Nexus, настройка самого Nexus, его настройка и поддержка могут оказаться излишними для такой простой проблемы, как использование одного jar-файла. Если этот сценарий — размещение пользовательских артефактов — является распространенным, однако, менеджер хранилища имеет большой смысл.
Загрузка артефакта в общедоступный репозиторий или в центральный Maven напрямую также является хорошим решением, но обычно является длительным . Кроме того, библиотека может вообще не поддерживать Maven, что значительно усложняет процесс, поэтому нереально решить возможность использования артефакта СЕЙЧАС. Это оставляет третий вариант — добавление артефакта в систему управления версиями и использование плагина maven — в этом случае, maven-install-plugin для его локальной установки до того, как процесс сборки понадобится . Это, безусловно, самый простой и надежный вариант.
2. Установите локальный jar с помощью maven-install-plugin
Давайте начнем с полной конфигурации, необходимой для установки артефакта в наш локальный репозиторий:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
|
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-install-plugin</artifactId> <version>2.4</version> <configuration> <groupId>org.somegroup</groupId> <artifactId>someartifact</artifactId> <version>1.0</version> <packaging>jar</packaging> <file>${basedir}/dependencies/someartifact-1.0.jar</file> <generatePom>true</generatePom> </configuration> <executions> <execution> <id>install-jar-lib</id> <goals> <goal>install-file</goal> </goals> <phase>validate</phase> </execution> </executions></plugin> |
Теперь давайте разберемся и проанализируем детали этой конфигурации.
2.1. Информация об артефакте
Информация об артефакте определяется как часть элемента <configuration> . Фактический синтаксис очень похож на объявление зависимости — groupId , artifactId и элементы версии . Следующая часть конфигурации требует определения упаковки артефакта — это указано как jar . Затем нам нужно указать местоположение фактического jar-файла, который нужно установить — это может быть абсолютный путь к файлу или относительный, используя свойства, доступные в Maven . В этом случае свойство $ {basedir} представляет корень проекта, а именно местоположение, в котором находится файл pom.xml . Это означает, что файл someartifact-1.0.jar необходимо поместить в каталог / dependencies / под корнем. Наконец, есть несколько других необязательных деталей, которые также можно настроить.
2.2. Выполнение
Выполнение цели установочного файла связано с этапом проверки из стандартного жизненного цикла сборки Maven. Это делается для того, чтобы артефакт был установлен в самом начале жизненного цикла, прежде чем он действительно потребуется на следующем этапе компиляции . Как только фаза компиляции действительно выполняется, наш someartifact-1.0.jar правильно установлен в нашем локальном репозитории, как и любой другой артефакт, который мог быть получен из самого Maven central.
2,3. Генерация пом против поставки пом
Вопрос о том, нужно ли нам предоставлять файл pom.xml для артефакта или нет, зависит главным образом от зависимостей самого артефакта во время выполнения . Проще говоря, если артефакт имеет зависимости времени выполнения от других jar-файлов, эти jar-файлы также должны присутствовать в пути к классам во время выполнения. С простым артефактом это не должно быть проблемой, так как он, скорее всего, не будет иметь зависимостей во время выполнения (лист в графе зависимостей). Опция generatePom в цели install-file должна быть достаточной для таких артефактов:
|
1
|
<generatePom>true</generatePom> |
Однако, если артефакт является более сложным и имеет нетривиальные зависимости , то, если эти зависимости еще не находятся в пути к классам, их необходимо добавить. Один из способов сделать это — определить эти новые зависимости вручную в файле pom проекта. Лучшее решение — предоставить пользовательский файл pom.xml вместе с установленным артефактом:
|
1
2
|
<generatePom>false</generatePom><pomFile>${basedir}/dependencies/someartifact-1.0.pom</pomFile> |
Это позволит Maven разрешить все зависимости артефакта, определенные в этом пользовательском файле pom.xml , без необходимости определять их вручную в основном файле pom проекта.
3. Вывод
В этой статье рассказывается, как использовать jar, который не размещен в проекте Maven, путем его локальной установки с помощью maven-install-plugin .