Как включить библиотечный jar в git project

Question

Как включить библиотечный jar в git project

1

У нас есть основной набор java-библиотек, публикуемых как файлы jar, которые используются в нескольких клиентских проектах. Проекты библиотек и клиентские проекты находятся на нашем сервере git (GitLab EE). Иногда клиенты и сторонние поставщики (например, субподрядчики) имеют доступ к исходному коду проекта, но мы не хотим, чтобы они имели доступ к источнику для основных java-библиотек.

Так что мне нужно знать, как настроить какую-либо зависимость или подобное в git, чтобы мы могли автоматически использовать последнюю версию файла библиотеки? Я смотрел на git submodule, но похоже, что он потянет или, по крайней мере, даст доступ к полному источнику библиотечных проектов. Я также начал смотреть на Maven, но неясно, нужен ли ему также доступ ко всему репозиторию. Есть ли другой/лучший способ сделать это? Или Мейвен действительно сделает то, что я хочу? Или мне нужно публиковать файлы jar в другом месте, и если да, то как я могу автоматизировать этот процесс, так как я не хочу вручную копировать файл jar где-нибудь каждый раз, когда он обновляется (что часто)?

Tom 02 апр. 2015, в 19:08

Источник

0

Maven - именно то, что используется для выполнения задач такого типа. Он управляет зависимостями в различных форматах (наиболее типичным является архив JAR) и гарантирует, что любой проект с зависимостями от некоторой библиотеки разрешит их при сборке приложения. По сути, он ищет «глобальный репозиторий» (чаще всего это Maven Central, но может быть где-нибудь удаленным) и загружает зависимые артефакты (jars) в локальное хранилище Maven пользователя, а Maven обрабатывает добавление этих путей в путь к классам, когда зависимый приложение построено. Нет необходимости в управлении исходным кодом или увидеть исходный код.
Ryan J 02 апр. 2015, в 16:31

Теги:

java

maven

git

jar

1 ответ

Ещё вопросы

Maven - именно то, что используется для выполнения задач такого типа. Он управляет зависимостями в различных форматах (наиболее типичным является архив JAR) и гарантирует, что любой проект с зависимостями от некоторой библиотеки разрешит их при сборке приложения. По сути, он ищет «глобальный репозиторий» (чаще всего это Maven Central, но может быть где-нибудь удаленным) и загружает зависимые артефакты (jars) в локальное хранилище Maven пользователя, а Maven обрабатывает добавление этих путей в путь к классам, когда зависимый приложение построено. Нет необходимости в управлении исходным кодом или увидеть исходный код.

Samuel · Accepted Answer · 2015-04-02T14-43-00.000Z

Maven и двоичный репозиторий, такой как Nexus, являются обычным способом делать то, что вы просите. Nexus хранит двоичные файлы, такие как.jar.dll и т.д., И Maven имеет возможность публиковать и получать определенные версии этих двоичных файлов и включать их при создании проекта. Как заметил Райан, Maven Central - это публичный двоичный репозиторий, который вы можете опубликовать, если хотите, чтобы весь мир был доступен для вашего.jars, но с Nexus у вас есть мелкий контроль доступа к вашим двоичным файлам.

Если вы создаете свои собственные проекты с помощью Maven, вы можете настроить его для сборки, тестирования и публикации в своем репозитории Nexus с помощью единой команды mvn deploy. Затем клиентам просто нужно обновить свой проект, чтобы указать на новую версию, и Maven загрузит его и будет использовать его в пути к классам. Все это очень плавно, и я определенно рекомендую реорганизовать процесс сборки для использования Maven или аналогичного продукта.

Спасибо за разъяснения Самуэлю (и Райану) - очень помогли. Похоже, у меня есть какое-то чтение, чтобы понять, как все это сочетается!