Как собрать локальный maven репозиторий без интернета

Обновлено: 04.07.2024

требуется ли maven подключение к интернету в какой-то момент, чтобы иметь возможность использовать его? Что конкретно означает получение внутренних плагинов maven для компиляции, очистки, упаковки и т. д.?

Вы можете запустить Maven в автономном режиме mvn -o install . Конечно, любые артефакты, недоступные в локальном репозитории, не будут работать. Maven не основан на распределенных репозиториях, но они, безусловно, делают вещи более бесшовными. Именно по этой причине многие магазины используют внутренние зеркала, которые постепенно синхронизируются с центральными репозиториями.

кроме того, mvn dependency:go-offline можно использовать, чтобы убедиться, что все ваши зависимости установлены локально, прежде чем вы начнете работать в автономном режиме.

Если у вас есть компьютер с доступом в интернет в локальной сети, необходимо установить локальный репозиторий Maven.

рекомендую Artifactory Open Source. Это то, что мы используем в нашей организации, это действительно легко установить.

Artifactory действует как прокси между вашим инструментом сборки (Maven, Ant, Ivy, Gradle и т. д.) и внешний мир.

Он кэширует удаленные артефакты, так что вам не придется загружать их снова и снова.

он блокирует нежелательные (и иногда чувствительные к безопасности) внешние запросы для внутренних артефактов и контролирует, как и где артефакты развертываются и кем.

после настройки Artifactory вам просто нужно изменить Maven's settings.xml в машинах развития:

мы использовали это решение, потому что у нас были проблемы с доступом в интернет в наших машинах разработки и некоторые артефакты скачали поврежденные файлы или не скачать вообще. Мы с тех пор у меня не было проблем.

у вас есть два варианта для этого:

1.) внести изменения в настройки.xml добавить в первый тег

2.) используйте тег-o для автономной команды.

Maven нуждается в зависимостях в вашем локальном репозитории. Самый простой способ получить их - это доступ в интернет (или сложнее использовать другие решения, представленные здесь).

таким образом, предполагается, что вы можете получить временный доступ в интернет вы можете подготовиться к работе в автономном режиме с помощью Maven-dependency-plugin С зависимость: go-offline цель. Это загрузит все ваши зависимости проекта в локальный репозиторий (конечно, изменения в зависимостях / плагинах потребуется новый доступ к интернету / центральному репозиторию).

к сожалению dependency:go-offline не работает для меня, так как он не кэшируется все, т. е. Файлы POMs и другие неявно упоминают зависимости.

обходной путь состоял в том, чтобы указать local repository location внутри С <localRepository>. </localRepository> или mvn С

перед переходом в автономный режим вы должны убедиться, что все находится в вашем локальном РЕПО, которое требуется при работе в автономном режиме. Запуск "mvn dependency: go-offline" для проекта(ов)/pom(ов), над которым вы собираетесь работать, сократит усилия по достижению этой цели.

но обычно это не вся история, потому что dependency: go-offline будет загружать только Плагины" голой сборки" (go-offline / resolve-плагины не разрешают все зависимости плагинов). Так что вы должны найти способ загрузки плагинов deploy / test / site (и, возможно, других) и их зависимостей в ваше РЕПО.

кроме того, зависимость: go-offline не загружает сам артефакт poms, поэтому вам нужно зависимость:скопируйте его, если требуется.

иногда - как писал МАДА-вы не знаете, что вам понадобится, находясь в автономном режиме, что делает довольно невозможным иметь "достаточное" РЕПО.

в любом случае, имея правильно заполненное РЕПО, вам нужно только добавить "правдаоффлайн>" настройки знатоки.xml для перехода в автономный режим.

Не изменяйте профиль Maven (id), который вы использовали для заполнения своего РЕПО, находясь в автономном режиме. Maven распознает загруженные артефакты в своих метаданных с помощью "идентификатора", который привязан к идентификатору профиля.

Если вы используете IntelliJ, вы можете просто перейти к предпочтения ->Сборка, Выполнение, Развертывание -> Build Tools ->Maven и установите / снимите флажок работа в автономном режиме.

при подготовке перед работой в автономном режиме просто запустите mvn dependency:go-offline

Как указать maven проекту, где искать дополнительный репозиторий

Для того, чтобы указать maven, что зависимости надо искать не только в умолчальном репозитории, существует штатный механизм. Вот так можно прописать ещё один адрес для поиска.

Далее мы подключили репозиторий проекта Spring, в котором можно найти последние версии этого семейства бибилиотек. Вот как это выглядит внутри pom.xml

Теперь maven, когда не найдёт зависимости в репозитории по умолчанию, или обнаружит, что оный недоступен — не запаникует, а поищет библиотеку в ещё одном репозитории и, если всё идёт по плану, найдёт её там. Тут следует уточнить, что если ваша программа может быть использована в качестве зависимости, например, если сама является библиотекой, то класть тег репозиторий в pom.xml — не лучшая идея. Объяснение того, почему это так, выходит за рамки статьи, но с ним можно ознакомиться тут.

Но бывает так, что библиотеки в репозиториях нет. Например, если это драйвера для MSSQL, или если это проприетарная библиотека, которую вы недавно приобрели за большие деньги.

Как быть, если библиотеки нет в удалённом хранилище по умолчанию, но она есть в другом удалённом хранилище

Первая и, возможно, самая частая проблема возникает, если библиотеки в этом умолчальном репозитории нет или в случае, если этот репозиторий с машины, на которой осуществляется сборка, недоступен, например, по соображениям безопасности.

Причины проблемы немного разные, но решение одинаковое — нужно указать репозиторий, в котором зависимости есть. Это либо какой-то другой адрес в Интернете, либо адрес репозитория, поднятого админами в локальной сети.

Что если ваша библиотека использует другую библиотеку?

Вопрос, казалось бы, глупый, но на всякий случай проведём эксперимент.

Сделаем библиотеку с непустыми зависимостями.

и напишем для неё код

Теперь соберём её

Перейдём в директорию с нашим проектом, который эту библиотеку использует и попробуем его собрать и запустить.

Итого

Maven ищет библиотеки в удалённом репозитории по умолчанию.
Чтобы подключить библиотеку, которой нет в репозитории по умолчанию, можно указать дополнительные удалённые репозитории, тогда maven будет искать библиотеки ещё и в них.
Если библиотеки нет ни в одном удалённом репозитории, то можно с помощью штатного механизма maven создать локальный репозиторий и добавить его в pom.xml.
При обновлении репозитория, который находится в исходниках проекта, нужно всегда менять версию библиотеки, иначе могут быть непонятные проблемы.
Если у вас есть maven проект, то из него можно сделать библиотеку командой mvn package.
Командой mvn install можно поместить библиотеку в локальный репозиторий по умолчанию.
Чтобы использовать библиотеку в другом проекте, достаточно указать её в качестве зависимости в pom.xml.

UPD: В комментариях sshikov, igor_suhorukov, jbaruch и другие высказали мнение, что библиотеки нельзя хранить вместе с исходниками, потому что для этого есть другие, предназначенные специально для этого инструменты, такие как Nexus и Artifactory.

Тут я совершенно согласен. Когда речь идёт о крупных проектах и корпоративной разработке, быть по-другому просто не может. Но, с моей точки зрения, есть случаи, когда удобнее сделать иначе. Я имею в виду маленькие проекты, созданные в процессе обучения, потому что именно с такими вещами обычно имеют дело новички, и случаи, когда доступа к инфраструктуре нет, а добавить библиотеку в сборку нужно в течение 10 минут. Нужно было с самого начала уточнить, что речь в статье именно о таких кейсах.

Да, хранить библиотеки в системе контроля версий — хак. Но, как и все хаки, это такая штука, которой в некоторых случаях можно пользоваться и о возможности осуществления которой неплохо бы знать.

Причины, по которым техника, предложенная в статье, не подходит для корпоративной разработки, хорошо раскрыты в комментариях. Также советую обратить внимание на статью от разработчиков Nexus, спасибо jbaruch за ссылку. Статья интересная, если не найду существующего перевода на Хабре, планирую перевести ее и сделать отдельным постом.

Как сделать свою java библиотеку

Для того, чтобы сделать библиотеку, достаточно написать класс с модификатором public. И потом можно будет использовать этот класс в коде, к которому подключена библиотека.

Вот такой, например, класс.

Теперь нужно сделать maven проект, который будет собирать библиотеку, содержащую этот класс.

Как мы помним, с точки зрения maven, библиотека — это просто артефакт, поэтому помник будет выглядеть тривиально.

Итак, у нас есть класс со статическим методом, у нас есть описание артефакта для maven. Осталось только собрать этот код, чтобы получилась библиотека, то есть jar файл.

Просто напишем в консоли:

После этого в директории target появится файл с названием \<artifactId>-\<version>.jar, в нашем конткретном случае — hello-world-library-1.0-SNAPSHOT.jar, который и есть ваша библиотека.

Как с помощью maven работать с библиотеками, которых в maven нет

В статье я расскажу, как подключить библиотеку, которой в maven по умолчанию нет, и как подключить другую библиотеку, исходники которой давным-давно потеряны.

Также я опишу, как сделать maven проект, который генерирует артефакт, по совместительству являющийся библиотекой, и как подключить эту библиотеку к другому своему же maven проекту.

Эта статья для тех, кто только начинает осваивать java.

В моей предыдущей статье было сказано, что maven сам скачает все указанные в pom.xml зависимости. А вот что будет, если он какую-нибудь зависимость не найдёт? В таком случае maven скажет, что зависимость не обнаружена и прервёт процесс сборки с ошибкой. Что делать в этом случае?

Этот вопрос, на самом деле, распадается на несколько вопросов, каждый из которых надо решать индивидуально. Выбор решения же определяется тем, где эта зависимость есть.

Зависимость может быть в интернете в каком-то месте, о существовании которого maven не знает. Ещё она может быть в виде jar файла у вас на руках и, наконец, в виде исходного кода, оформленного как maven проект.

Об этих трёх случаях мы и поговорим.

Но сначала надо коротко прояснить один вопрос.

Как сделать свою java библиотеку

Вот такой, например, класс.

Теперь нужно сделать maven проект, который будет собирать библиотеку, содержащую этот класс.

Просто напишем в консоли:

Как подключить свежесозданную библиотеку к своему maven проекту

Для того, чтобы библиотеку потом можно было подключать к другому проекту, нужно вместо package написать install.

Это нужно будет делать после каждого изменения в коде библиотеки, и на каждом компьютере, на котором мы захотим эту библиотеку использовать.

Теперь можно сделать новый проект, который будет использовать библиотеку.

Внутри проекта будет один класс, который использует статический метод из библиотеки, чтобы сказать Hello world. Мы этот класс уже видели.

Проверим ещё раз:

Работает не хуже предыдущего варианта!

Как подключить библиотеку, которой в репозиториях нет

Подключить такую библиотеку можно несколькими способами. Например, если у вас есть свой репозиторий в локальной сети, то можно (а иногда даже нужно), положить библиотеку туда, и тем самым свести задачу к предыдущей.

Но, если это возможно, такую библиотеку лучше положить в проект и хранить прямо в системе контроля версий. Тогда библиотека будет доступна программе всегда и на любой машине, а шаг по копированию этой библиотеки в репозиторий можно не включать в мануал.

Для обработки таких кейсов у maven тоже есть штатный механизм. Только что мы выяснили, как указать maven удалённый репозиторий, отличный от умолчального. Так вот, не обязательно использовать удалённое хранилище. Можно сделать репозиторий в локальной файловой системе, положить туда библиотеку и проинструктировать maven искать зависимости ещё и там.

Как подключить свежесозданную библиотеку к своему maven проекту

Для того, чтобы библиотеку потом можно было подключать к другому проекту, нужно вместо package написать install.

Теперь можно сделать новый проект, который будет использовать библиотеку.

Проверим ещё раз:

Работает не хуже предыдущего варианта!

Как создать свой локальный репозиторий

Для этого, как сказано выше, у maven есть штатное средство.

Допустим у нас есть библиотека, которая находится в jar файле под названием hello-world-library-1.0-SNAPSHOT.jar. О библиотеке нам известно, что в ней есть один класс HelloWorld, который включает один статический метод say, печатающий в консоли, как несложно догадаться, Hello World.

Мы хотим в директории проекта создать директорию lib, в которой будет находиться наш дополнительный репозиторий, и поместить туда библиотеку. Для этого достаточно в директории проекта выполнить следующую команду.

Если вы используете операционную систему Windows, нужно заменить \ на ^, то есть написать

Или можно просто убрать \ и написать команду в одну строчку.

Обратите внимание, как и для любого другого артефакта, для библиотеки нам нужно придумать groupId, artifactId и version. Мы потом укажем их в pom.xml, когда будем подключать зависимость.

Внутри директории, которую создаст команда, находится полноценный репозиторий, для использования которого достаточно указать maven, где он находится. Все сведения о том, какие библиотеки можно там найти, содержатся непосредственно в структуре директорий свежесозданного репозитория. Для последующего использования репозитория, например, на других машинах, команду deploy-file выполнять не надо.

Дать проекту знать, что репозиторий существует, и показать, где он находится, можно уже описанным способом, правда, с поправкой на то, что репозиторий локальный.

Обратите внимание на пятую строку

Тут сказано, что искать репозиторий надо в директории проекта, на которую указывает встроенная переменная maven project.basedir.

Класс, использующий библиотеку, будет предельно прост, но для порядка приведём его код.

Осталось добавить в pom.xml зависимость и можно собирать проект.

Директорию lib надо закомитить и библиотека будет доступна проекту вообще всегда.

Однако следует помнить об одном правиле.

Нужно обязательно обновлять номер версии библиотеки в локальном репозитории при каждом изменении jar файла

Maven воспринимает репозитории как внешние, поэтому, если не изменить номер версии, то maven будет использовать не версию библиотеки из директории lib, а ту, что он закешировал на локальной машине. В данном конкретном случае это не должно сыграть роли из-за суффикса SNAPSHOT, но об этом нужно знать.

Есть ещё один распространённый сценарий. У вас есть своя библиотека, которую вы сами собираете с помощью maven и потом подключаете к другому maven проекту.

Как это работает

Строго говоря знать, как процесс устроен внутри, не обязательно, но всё равно очень полезно.

Команда mvn install соберёт библиотеку, а потом положит её в локальный репозиторий по умолчанию. То есть в то же самое место, где лежат все библиотеки, которые вы когда-либо подключали к maven проектам, за исключением, разумеется, тех, которые находятся в локальных репозиториях, сделанных лично вами.

Потом, при сборке проекта, использующего эту библиотеку, maven поищет её в локальном хранилище, найдёт и подключит.

Build Systems — Local Repository

Продолжение предыдущего поста о системах сборки — BuildSystems — Intro

Maven

Система сборки, описывающая зависимости на разных уровнях и плагины для выполнения задач.
В предыдущем посте есть ссылки на другие статьи, где описывается данная система, отличительной чертой которой является четко выраженный жизненный цикл сборки:

validate — проверяет корректность таинформации о проекте
compile — компилирует исходники, фактически это обращение к плагину «compiler»;
test — запуск юнит-тестов
package — упаковка классов в заданный формат (zip, rar, jar, war, ear и т.д.)
integration-test -запуск интеграционных тестов после сборки
verify — проверяет корректность пакета и удовлетворение требованиям качества
install — «установка» сборки в локальный репозиторий
deploy — отправка пакета на заданный сервер

Локальный репозиторий Maven

Но ни в одной из этих статей не описано, что в свою очередь, для меня было очень полезным — это настройка локального репозитория.

По умолчанию, в качестве локального репозитория используется следующая директория (OS:Windows)

Но со временем репозиторий всё растёт и растёт и меня этот факт, постоянно отжирающий на системном разделе место, начал разочаровывать прямо-пропорционально росту репозитория.
К тому же, если вдруг у вас (как у меня) настроено несколько пользователей, с которыми вы работаете, то два таких дублирующихся репозитория начинают расстраивать в два раза больше.

Чтобы этого не происходило, есть хорошее и элегантное решение — перенести локальный репозиторий на другой раздел и настроить всех пользователей на него.
Для этого открываем файл

Где добавляем настройку локального репозитория

При использовании локального репозитория, размер директории ".m2" остается равным порядка 114Кб.

Использование плагинов

Также хочу привести немного расширенный пример работы с плагинами, для создания проектов по архетипу.

Создание проекта для Eclipse

Создание проекта для IDEA

Но когда у вас выполнение данных команд не приносит желаемого результата, следует посмотреть справку для вызываемого плагина, которую можно вызвать следующим образом:

где будет описана конфигурация и возможные параметры для плагина, к которому вы обращаетесь.

А что касается генерации, то запросить справку по архетипам можно следующим образом:

Ant + Ivy

Ant — ещё одна система сборки
Ivy — менеджер зависимостей, который умеет обращаться к различным репозиториям и находить в них нужную информацию и подгружать её в локальный репозиторий (некоторый кэш, на локальной машине).

Ant, на мой взгляд, дает большую степень свободы, чем Maven (в котором, кстати, тоже можно обращаться к задачам/таскам ant'a), хотя бы потому, что вам для того, чтобы автоматизировать один из нужных этапов вашей сборки не придется для этого реализовывать собственный плагин для Maven. Другими словами Ant больше приспособлен к быстрой автоматизации тех или иных действий для сборки вашего проекта и где любой ваш шаг в сторону не будет расценен как побег и караться расстрелом.

— описание с примерами тасок компиляции и упаковки; — хороший пример интеграции Ant+Tomcat и использование тасок установки сборки на сервер, определение окружения сервера, старт/остановка сервера и даже обнаружение утечек памяти (find leaks); — примеры использования Ivy; — отличный пример широкого применения Ant с подключением JavaFX.

Локальный репозиторий Ivy

Аналогичная проблема с размещением и настройкой локального репозитория Ivy, который по умолчанию располагается в

Конфигурация системы читается из «ivysettings.xml», который можно также подключить следующим образом:

А вот размещение самого локального репозитория можно переопределить в секции «caches», указав атрибут «defaultCacheDir»: