проблемы популярных подходов
Большинство ответов, которые вы найдете в Интернете, предложат вам либо установить зависимость в локальном репозитории, либо указать область действия «system» в pom и распространить зависимость с источником вашего проекта. Но оба эти решения на самом деле несовершенны.
Почему не следует применять подход «Установка в локальный репо»
Когда вы устанавливаете зависимость в свой локальный репозиторий, он остается там. С вашим артефактом распространения все будет хорошо, если у него есть доступ к этому хранилищу. Проблема в том, что в большинстве случаев этот репозиторий будет находиться на вашем локальном компьютере, поэтому не будет никакого способа разрешить эту зависимость на любом другом компьютере. Очевидно, что зависимость вашего артефакта от конкретной машины - это не способ справиться с ситуацией. В противном случае эта зависимость должна быть установлена локально на каждой машине, работающей с этим проектом, что не лучше.
Почему вы не должны применять подход "Scope System"
Банки, от которых зависит подход System Scope, не устанавливаются ни в какой репозиторий и не подключаются к целевым пакетам. Вот почему ваш дистрибутив не сможет решить эту зависимость при использовании. Именно это, я считаю, и стало причиной того, что использование системной области даже устарело. В любом случае, вы не хотите полагаться на устаревшую функцию.
Решение статического репозитория в проекте
После помещения этого в ваш pom:
<repository>
<id>repo</id>
<releases>
<enabled>true</enabled>
<checksumPolicy>ignore</checksumPolicy>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
<url>file://${project.basedir}/repo</url>
</repository>
для каждого артефакта с идентификатором группы в форме x.y.z Maven будет включать следующее местоположение в директории вашего проекта при поиске артефактов:
repo/
| - x/
| | - y/
| | | - z/
| | | | - ${artifactId}/
| | | | | - ${version}/
| | | | | | - ${artifactId}-${version}.jar
Подробнее об этом вы можете прочитать в этом блоге .
Используйте Maven для установки в репозиторий проекта
Вместо создания этой структуры вручную, я рекомендую использовать плагин Maven для установки ваших jar-файлов в качестве артефактов. Итак, чтобы установить артефакт в репозиторий в проекте в папке repo, выполните:
mvn install:install-file -DlocalRepositoryPath=repo -DcreateChecksum=true -Dpackaging=jar -Dfile=[your-jar] -DgroupId=[...] -DartifactId=[...] -Dversion=[...]
Если вы выберете этот подход, вы сможете упростить объявление репозитория в pom до:
<repository>
<id>repo</id>
<url>file://${project.basedir}/repo</url>
</repository>
вспомогательный скрипт
Поскольку выполнение команды установки для каждой библиотеки является довольно раздражающим и определенно подверженным ошибкам, я создал служебный скрипт , который автоматически устанавливает все файлы jar из папки lib в репозиторий проекта, при этом автоматически разрешение всех метаданных (groupId, artifactId и т. д.) из имен файлов. Сценарий также выводит на экран xml-зависимости для копирования-вставки в pom.
Включите зависимости в целевой пакет
Когда вы создадите свой репозиторий в проекте, вы решите проблему распределения зависимостей проекта с его источником, но с тех пор целевой артефакт вашего проекта будет зависеть от неопубликованных jar-файлов, поэтому, когда вы Установлю его в репозиторий, у него будут неразрешимые зависимости.
Чтобы решить эту проблему, я предлагаю включить эти зависимости в ваш целевой пакет. Это можно сделать либо с помощью Assembly Plugin , либо лучше с OneJar Plugin . Официальную документацию по OneJar легко понять.