Как добавить dependency в maven для чего они нужны откуда они скачиваются

Maven в вопросах и ответах

На странице рассмотрены следующие вопросы использования фреймворка Maven :

Команда создания нового проекта

Для создания нового проекта используется плагин archetype с целью (goal) generate. В команде необходимо указать параметры GAV (groupId, artifactId, version) и тип артефакта archetypeArtifactId. Количество разнотипных артефактов у фреймворка maven огромно. Пример копирования наименований архитипов в файл и создания простого maven-проекта :

Структура файла описания проекта pom.xml

При описании проекта в файле pom.xml используются следующие теги и секции :

Не все секции файла описания проекта pom.xml являются обязательными.

GAV-параметры и полное наименование артефакта

Параметры артефакта GAV включают groupId, artifactId, version. Полное имя артефакта (координата) представляет четыре слова, разделенные знаком двоеточия в следующем порядке groupId:artifactId:packaging:version.

Назначение SNAPSHOT

SNAPSHOT используется в определении версии артефакта и обозначает незавершенность её разработки. При каждой сборке проекта maven проверяет наличие обновленной версии snapshot артефакта в удалённом репозитории и подгружает последний.

Область действия зависимости scope

Область действия зависимости scope определяет этап жизненного цикла проекта, в котором эта зависимость будет использоваться. Maven использует 6 областей :

Использование внешних зависимостей

В качестве внешних зависимостей, как правило, используются собственные разработки, не размещаемые в центральном и локальном репозиториях. Внешние зависимости определяются в файле pom.xml также, как и другие зависимости – необходимо определить параметры GAV (groupId, artifactId, version) и область видимости scope как system. В теге необходимо указать абсолютный путь к файлу.

Транзитивные зависимости

Транзитивные зависимости позволяют избегать необходимости дополнительного указания в секции dependencies библиотек, которые требуются для самой зависимости, и maven включает их в проект автоматически. При разрешении конфликта версий используется принцип «ближайшей» зависимости, то есть выбирается зависимость, путь к которой через список зависимых проектов является наиболее коротким.

Команды «mvn depenency:list» и «mvn dependency:tree» позволяют вывести в консоль зависимости в виде списка или дерева соответственно.

Maven плагины

Maven использует два типа плагинов :

Плагины используются для :

Порядок выполнения maven команды

Как будет выполнена следующая команда

Аргументы clean и package являются фазами сборки проекта, «dependency:copy-dependencies» представляет собой задачу, которую выполняет плагин dependency для цели copy-dependencies (копирование зависимостей проекта в поддиректорию target/dependency).

Maven сначала выполнит фазу очистки clean, после этого будут скопированы зависимости «dependency:copy-dependencies», и в завершении выполнится сборка проекта.

Тестирование проекта

Для выполнения JUnit тестов проекта необходимо выполнить команду «mvn test». Чтобы выполнить определенный тест необходимо в командной строке указать полный путь [-Dtest=package.test-class] к конкретному тесту, например :

Для запуска сборки проекта с предварительной очисткой поддиректории «target» без выполнения тестов используйте следующую команду :

Примечание : помните, что запретив выполнение тестов в файле pom.xml, нельзя будет выполнять тесты с помощью Maven.

Maven репозитории

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

Используемые в проекте внешние репозитории описываются в секции :

Предопределёные переменные в файле pom.xml

При описании проекта в файле pom.xml можно использовать переменные, на которые можно сослаться с помощью префиксов «project.» или «pom.» Наиболее часто используемые элементы :

Источник

Maven. Часть 2 – Dependency

В этом уроке я вам покажу основную силу Maven, а именно как создать проект, который можно разрабатывать целой командой и при этом не потребуется каждому члену команды подключать необходимые библиотеки к проекту, давайте начнем.
И так начнем с того, зачем вам нужен Maven? В статье Maven. Часть 1 – Знакомство и настройка мы уже немного разобрали что это и как настроить.

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

Шаг 1. Создание Maven проекта

Запускаем нашу всем любимую Intellij IDEA и нажимаем File->Create New Project

Шаг 2.

Теперь в корне проекта вы должны увидеть файл pom.xml.

И вот что вы должны видеть:

С помощью этого файла и осуществляется настройка сборки вашего проекта. К примеру вам нужно собрать проект в *.jar файл, для этого вам достаточно указать это в pom.xml. Как собрать проект в jar файл вы можете посмотреть тут.

Это файл изначально имеет default (поумолчанию) структуру.

Шаг 3. Используем Dependency

Что же такое dependency и для чего они нужны?

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

Рассмотрим на базовом шаблоне:

В выше приведенном примере я продемонстрировал подключение библиотеки JUnit 4.11 к проекту, теперь при сборке проекта эта библиотека упакуется в мой *.jar или *.war архив, а также теперь мы в наших классах можем обращаться к объектам библиотеки JUnit.

– тут мы размещаем список dependency (библиотек), которые используются в проекте;

– библиотека используемая проектом;

– идентификатор группы библиотеки;

Шаг 4. Структура проекта

Стандартная структура каталогов:

Стандартная структура каталогов — одна из реализаций этого принципа.

Поскольку проект её придерживается, отпадает необходимость специфицировать пути к файлам, что сильно упрощает pom.xml.

Следующая структура показывает важнейшие каталоги.

Корневой каталог проекта:

– pom.xml и все дальнейшие подкаталоги;

– src: все исходные файлы;

src/main : исходные файлы собственно для продукта;

src/main/java : Java-исходный текст;

src/main/resources : другие файлы, которые используются при компиляции или исполнении, например Properties-файлы;

src/test : исходные файлы, необходимые для организации автоматического тестирования;

src/test/java : JUnit-тест-задания для автоматического тестирования;

target : все создаваемые в процессе работы Мавена файлы;

target/classes : компилированные Java-классы.

Шаг 5. Жизненный цикл

Жизненный цикл проекта — это список поименованных фаз, определяющий порядок действий при его построении.

Maven использует по умолчанию следующий жизненный цикл:

1) archetype – создание темплейта и обработка ресурсов. На этой фазе разрешаются и, при необходимости, скачиваются из интернета зависимости;

2) compile – компиляция;

3) обработка тестовых ресурсов (например — скачивается из интернета JUnit-пакет);

4) компиляция тестов (тестирующие классы не передаются конечным пользователям);

5) test – тестирование;

6) package – упаковка (обычно речь идёт о создании JAR– или WAR-файла);

7) install – инсталляция проекта в локальном Maven-репозитории (теперь он доступен как модуль для других локальных проектов);

8) deploy – инсталляция в удаленном Maven-репозитории (теперь стабильная версия проекта доступна широкому кругу разработчиков).

Maven имеет также стандартный жизненный цикл для чистки (cleaning) и для генерации его страницы (site). Если бы ‘clean’ было частью обычного жизненного цикла, проект подвергался бы чистке при каждом построении, что нежелательно.

Стандартные жизненные циклы могут быть существенно дополнены Maven-плагинами и Maven-архетипами.

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

Источник

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

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

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

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

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

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

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

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

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

Откуда maven качает библиотеки

На просторах интернета есть сервер, на котором выложены java библиотеки. Этот сервер называется репозиторием, а по-русски — хранилищем. Это не какой-то абстрактный, а вполне конкретный ресурс, адрес которого зашит в дефолтные настройки maven. Поэтому он называется репозиторием по умолчанию. Именно там maven будет искать зависимости из pom.xml.

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

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

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

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

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

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

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

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

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

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

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

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

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

Для этого, как сказано выше, у 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 проекту.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итого

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

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

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

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

Источник

Как с помощью maven подключить библиотеку к проекту

Спросите кого-нибудь, для чего вообще нужен Maven — 90 процентов поголовья программистов ответит, что именно для этого и будут во многом правы.

Если в случае с, например, C++ подключение библиотеки к своему проекту — это серьёзный шаг, который гарантированно усложнит сборку до такой степени, что придётся включить инструкции по подключению данной конкретной библиотеки в readme, то в случае с Java это делается легко и непринуждённо — не в последнюю очедь благодаря Maven.

Хочу отметить, что статья предназначена для тех, кто начал изучать java относительно недавно и хотя уже значет из предыдущей статьи, что такое maven — о том, что такое библиотеки, знает не очень хорошо, а как их подключать не знает вообще.

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

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

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

Предлагаю присутствущим потратить минуту-другую на выражение благодарности капитану Очевидность, а после продолжить чтение.

Как добавить в проект класс, написанный кем-то другим

Ответ, вообще говоря, очевиден — надо скопировать этот класс в свой код.

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

Классы, используемые каким-то другим классом, кстати, принято называть зависимостями (dependencies), этого класса.

У такого подхода есть очевидный минус. Для каждого класса надо выискивать зависимости, а потом руками копировать их к себе. Если позже во всей этой куче кода найдётся какой-нибудь баг, то после появления фикса придётся повторить процесс заново.

Как добавить в проект класс, написанный кем-то другим, не копируя его в свой код

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

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

Если вы работаете с Java то понимать, что такое classpath — строго обязательно, но конкретно для того, чтобы добавить к проекту библиотеку с помощью maven, этого знать не нужно. В контексте нашей темы можно считать classpath сущностью, в которой перечислены все места, где компилятор будет искать классы, необходимые приложению. Если какого-нибудь из этих классов нет ни в одном из этих мест, то программа работать не будет.

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

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

Вот собственно мы и подошли к ответу на вопрос, что такое библиотека.

Что такое библиотека

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

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

Ещё можно заархивировать скомпилированный код в формате zip, поменять расширение файла с архивом на jar и добавить в classpath файл уже этот файл. В контексте разработки на Java, jar файл тоже называется библиотекой.

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

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

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

Как добавить в проект библиотеку, использующую другую библиотеку

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

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

Как убедиться, что обновление зависимости ничего не сломает

Сторого говоря — никак.

Необходимо, конечно, обновить зависимость и запустить юнит тесты. Если они не проходят, то определённо можно сказать, что что-то сломалось.

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

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

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

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

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

Этот идентификатор принято называть версией библиотеки.

Версию библиотеки программист обновляет не только при исправлении ошибок, но и вообще при любом изменении.

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

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

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

При обновлении какой-нибудь из библиотек процесс надо повторить. Это, поверьте мне, мучительно.

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

И тут на помощь приходит Maven. Он формализует негласную договорённость между программистами и делает её гласной.

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

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

Эти вопросы в Maven успешно решены.

Как подключить библиотеку к Maven проекту

Тут всё в общем-то банально. Библиотека в понимании Maven, является артефактом, нужным для сборки программы.

У каждого артефакта, как мы помним, есть groupId, artifactId и version. Нужно только указать maven, что данный артефакт является зависимостью проекта.

Список зависимостей должен быть обернут тегом dependencies. Каждая отдельная зависимость должна быть обёрнута тегом dependency. Внутри тега dependency в тегах groupId, artifactId и version нужно указать значения соответствующих параметров.

Тут наверное надо дать пример pom.xml с добавленной библиотекой. Вот пример:

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

Чтобы скомпилировать код надо написать

Этот код выведет Hello world, но, в отличии от предыдущей статьи, уже новым прогрессивным методом. С помощью библиотеки.

Вот собственно и всё.

Зависимости подключённого к проекту артефакта maven найдёт сам, сам составит список всех библиотек, необходимых проекту, включая зависимости зависимостей и зависимости зависимостей зависимостей, сам скачает их на машину, на которой происходит сборка и сам добавит их в classpath.

Источник