Оригинал статьи — http://www.geekality.net/2013/09/16/maven-add-3rd-party-dependencies-in-project-specific-repository/
Если вам нужно подключить в maven-е какие-то свои библиотечки, которых нет в публичном Maven-репозитории, это делается в 3 шага:
Нашу библиотечку нужно задеплоить — распаковать lib. Делается это такой командой (она записана в несколько строк только наглядности ради, так то, разумеется, вы пишите ее одной строкой):
mvn deploy:deploy-file
-Durl=file:///dev/project/repo/
-Dfile=somelib-1.0.jar
-DgroupId=com.example
-DartifactId=somelib
-Dpackaging=jar
-Dversion=1.0
groupId и artifactId — вы можете называть сами как хотите. Например, вы можете в качестве artifact id использовать название библиотечки, а в качестве group id — id в главном пакете, используемом в библиотеке.
The group and artifact id you’d have to make up yourself of course. For example pull the artifact id from the library name and the group id from the main package used inside the library.
Не забудьте добавить эту папку в систему контроля версий!
Добавьте в свой pom.xml следующий код, чтобы дать Maven-у знать о только что созданном репозитории.
<repositories>
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${project.basedir}/repo</url>
</repository>
</repositories>
И наконец, подключите в pom.xml саму библиотечку. Ведь раньше вы только указали, где она будет лежать, а теперь уже показываете, что ее надо использовать в проекте, вот эту конкретную, с такими то идентификаторами:
<dependency>
<groupId>com.example</groupId>
<artifactId>somelib</artifactId>
<version>1.0</version>
</dependency>
Все просто и понятно ツ
Как я дошла до жизни такой? У меня есть тестовый проект Folks, на котором можно посмотреть, как могут работать API-тесты. Исходно код собирался в zip-архивчик, распаковал и работает. Сейчас я проект «причесываю», первая стадия — собрать его мавеном.
Что мы и делаем. Можете попробовать сами.
Исходно код.
Результат моих усилий.
Скачиваем исходный код, zip-ничек. Удаляем все "лишние" библиотеки, которые мавен осилит выкачать сам из общедоступных репозиториев. Должны остаться только:
Если вам нужно подключить в maven-е какие-то свои библиотечки, которых нет в публичном Maven-репозитории, это делается в 3 шага:
1. Создать репозиторий
Нашу библиотечку нужно задеплоить — распаковать lib. Делается это такой командой (она записана в несколько строк только наглядности ради, так то, разумеется, вы пишите ее одной строкой):
mvn deploy:deploy-file
-Durl=file:///dev/project/repo/
-Dfile=somelib-1.0.jar
-DgroupId=com.example
-DartifactId=somelib
-Dpackaging=jar
-Dversion=1.0
groupId и artifactId — вы можете называть сами как хотите. Например, вы можете в качестве artifact id использовать название библиотечки, а в качестве group id — id в главном пакете, используемом в библиотеке.
The group and artifact id you’d have to make up yourself of course. For example pull the artifact id from the library name and the group id from the main package used inside the library.
Не забудьте добавить эту папку в систему контроля версий!
2. Определить репозиторий
Добавьте в свой pom.xml следующий код, чтобы дать Maven-у знать о только что созданном репозитории.
<repositories>
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${project.basedir}/repo</url>
</repository>
</repositories>
3. Определить зависимости
И наконец, подключите в pom.xml саму библиотечку. Ведь раньше вы только указали, где она будет лежать, а теперь уже показываете, что ее надо использовать в проекте, вот эту конкретную, с такими то идентификаторами:
<dependency>
<groupId>com.example</groupId>
<artifactId>somelib</artifactId>
<version>1.0</version>
</dependency>
Все просто и понятно ツ
Пример из жизни
Как я дошла до жизни такой? У меня есть тестовый проект Folks, на котором можно посмотреть, как могут работать API-тесты. Исходно код собирался в zip-архивчик, распаковал и работает. Сейчас я проект «причесываю», первая стадия — собрать его мавеном.
Что мы и делаем. Можете попробовать сами.
Исходно код.
Результат моих усилий.
Скачиваем исходный код, zip-ничек. Удаляем все "лишние" библиотеки, которые мавен осилит выкачать сам из общедоступных репозиториев. Должны остаться только:
- jira-soap-4.4.0.jar
- parent-resources-4.0-SNAPSHOT.jar
- utils-core-1.5.1-SNAPSHOT.jar
- utils-io-1.5.1-SNAPSHOT.jar
- utils-lucene-1.5.1-SNAPSHOT.jar
- utils-spring-1.5.1-SNAPSHOT.jar
- utils-test-1.5.1-SNAPSHOT.jar
Допустим, что они лежат в папке D:\hgprojects\folks\lib
1. Деплоим джарники. Начинаем с одного:
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=jira-soap-4.4.0.jar -DgroupId=org.swift.common -DartifactId=jira-soap -Dpackaging=jar -Dversion=4.4.0 -DpomFile=pom-jira.xml
Почему строка выглядит именно так?
- url — место, где лежит джарник;
- file — название файла;
- packaging — тип файла, у нас это jar
- groupId, artifactId, version — заходим внутрь jar → META-INF → maven → org.swift.common → jira-soap → pom.properties. Там все эти 3 параметра уже есть
- pomFile — заходим по тому же пути, рядом с pom.properties лежит pom.xml. Достаем его из джарника и переименовываем, так как он будет не единственный помник. Ну, я их уже все распаковала ツ
Сначала я деплоила их без параметра -DpomFile, но увы, ничего не сработало. Потому что без этого параметра деплоится простой файл. А если внутри библиотеки есть свои собственные зависимости, то внутри лежит pom.xml, а вам надо его указать. Иначе система ничего не будет знать о дополнительных зависимостях, а без них ваш проект не задеплоится.
Итого получилось:
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=jira-soap-4.4.0.jar -DgroupId=org.swift.common -DartifactId=jira-soap -Dpackaging=jar -Dversion=4.4.0 -DpomFile=pom-jira.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-core-1.5.1-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=utils-core -Dpackaging=jar -Dversion=1.5.1-SNAPSHOT -DpomFile=pom-core.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-io-1.5.1-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=utils-io -Dpackaging=jar -Dversion=1.5.1-SNAPSHOT -DpomFile=pom-io.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-lucene-1.5.1-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=utils-lucene -Dpackaging=jar -Dversion=1.5.1-SNAPSHOT -DpomFile=pom-lucene.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-spring-1.5.1-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=utils-spring -Dpackaging=jar -Dversion=1.5.1-SNAPSHOT -DpomFile=pom-spring.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-test-1.5.1-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=utils-test -Dpackaging=jar -Dversion=1.5.1-SNAPSHOT -DpomFile=pom-test.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=utils-1.5.1-SNAPSHOT.pom -DgroupId=ru.hflabs -DartifactId=utils -Dversion=1.5.1-SNAPSHOT
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=parent-4.0-SNAPSHOT.pom -DgroupId=ru.hflabs -DartifactId=parent -Dversion=4.0-SNAPSHOT
(чекстайл вынесла в корневой, после деплоя записать в relativePath)
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=parent-resources-4.0-SNAPSHOT.jar -DgroupId=ru.hflabs -DartifactId=parent-resources -Dpackaging=jar -Dversion=4.0-SNAPSHOT -DpomFile=pom-parent.xml
mvn deploy:deploy-file -Durl=file://D:\hgprojects\folks\lib -Dfile=checkstyle.xml -DgroupId=ru.hflabs -DartifactId=parent-resources -Dpackaging=jar -Dversion=4.0-SNAPSHOT -DpomFile=pom-parent.xml
Директорию «new pom» вообще удалила, зато в корневой все нужное перенесла.
2. Определяем репозиторий. Внутрь корневого pom.xml добавляем
<repositories>
<repository>
<id>project.local</id>
<name>project</name>
<url>file:${project.basedir}/lib</url>
</repository>
</repositories>
То есть место хранения — в папке lib, которая находится в корне нашего проекта.
3. Определяем зависимости. Внутрь корневого pom.xml добавляем
<dependency>
<groupId>org.swift.common</groupId>
<artifactId>jira-soap</artifactId>
<version>4.4.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>ru.hflabs</groupId>
<artifactId>utils-test</artifactId>
<version>${ru.hflabs.util.version}</version>
<scope>test</scope>
</dependency>
И так далее, посмотреть можно в коде.
Версии некоторые вынесла наверх, в блок properties. Так код выглядит красивее, мне так разработчик сказал ツ
Так как мы деплоили еще и помник, то нужно указать ссылку на него распакованного (это корневой POM для тех библиотек, которые мы подключаем, он внутри parent был):
<relativePath>lib/ru/hflabs/parent/4.0-SNAPSHOT/parent-4.0-20170829.091629-1.pom</relativePath>
4. Проверяем. После всех настроек пробуем собрать проект. На самом деле можно на любой стадии пробовать, но будем видеть ошибки «не могу найти твои сторонние файлы, подключи их». Для сбора проекта используем команду
mvn clean install -Dmaven.test.skip=true -U
На всякий случай я сохранила все исходники библиотек, распакованные из них помники и свои команды в архиве lib_folks.zip. Потому что фактически джарник — это запакованная информация. Мы ее распаковали. И если все получилось и билд собрался, то все исходники мы просто... удаляем. Да да! Они нам больше не нужны. Но на всякий случай можно и сохранить =))
Комментариев нет:
Отправить комментарий