Во-первых, я хотел бы отдать должное этому ответу анонимному пользователю Переполнения стека - я почти уверен, что видел подобный ответ здесь раньше - но теперь я не могу его найти.
Лучшим вариантом для использования локальных файлов JAR в качестве зависимости является создание локального репозитория Maven.Такой репозиторий - не что иное, как правильная структура каталогов с файлами pom в нем.
Для моего примера: у меня есть мастер-проект в ${master_project}
location, а subproject1 в ${master_project}/${subproject1}
.
Затем я создаю репозиторий Maven в: ${master_project}/local-maven-repo
.
В файле pom в подпроекте1, расположенном по адресу ${master_project}/${subproject1}/pom.xml
, необходимо указать хранилище, в котором в качестве параметра URL будет указан путь к файлу:
<repositories>
<repository>
<id>local-maven-repo</id>
<url>file:///${project.parent.basedir}/local-maven-repo</url>
</repository>
</repositories>
Зависимость можно указать, как и для любого другого хранилища.Это делает ваш репозиторий POM независимым.Например, как только требуемый JAR будет доступен в Maven Central, вам просто нужно удалить его из локального репо, и он будет извлечен из репо по умолчанию.
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.servicebinder</artifactId>
<version>0.9.0-SNAPSHOT</version>
</dependency>
Последнее, но не менее важное, это добавление файла JAR в локальный репозиторий с помощью ключа -DlocalRepositoryPath, например:
mvn org.apache.maven.plugins:maven-install-plugin:2.5.2:install-file \
-Dfile=/some/path/on/my/local/filesystem/felix/servicebinder/target/org.apache.felix.servicebinder-0.9.0-SNAPSHOT.jar \
-DgroupId=org.apache.felix -DartifactId=org.apache.felix.servicebinder \
-Dversion=0.9.0-SNAPSHOT -Dpackaging=jar \
-DlocalRepositoryPath=${master_project}/local-maven-repo
После установки файла JAR вашРепозиторий Maven может быть передан в репозиторий кода, и вся установка не зависит от системы.( Рабочий пример в GitHub ).
Я согласен, что использование JAR-файлов для репозитория исходного кода не является хорошей практикой, но в реальной жизни быстрые и грязные решения иногда лучше, чем полноевзорванный репозиторий Nexus для размещения одного JAR, который вы не можете опубликовать.