Получи случайную криптовалюту за регистрацию!

​​В продолжение предыдущей темы: как подключать библиотеки. | Java кабала

​​В продолжение предыдущей темы: как подключать библиотеки.

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

Давайте представим, что мы хотим создать библиотеку, что нам нужно? Ну очевидно, в первую очередь написать исходный код - это непосредственно код нашей библиотеки. Ну окей, написали. Теперь нам нужно покрыть это дело тестами - но вот не задача, чтобы написать тесты, нам нужны зависимости в виде других библиотек, типа junit, spock, mockito и др.

Хаха, давайте сачканем, и пока пропустим тесты (но только в этом случае). Что дальше? Нам нужно скомпилировать все наше добро - ну ок, у нас вроде есть javac. Но что толку с кучи скомпилированных классов? Нам нужно их упаковать! Упаковать в JAR (Java Archive). Вы скажете: «Ну окей, руками создам архив и все туда сложу». Как бы да, никто не запрещает этого вам сделать, но дальше начинается самое интересное - нам нужно опубликовать нашу библиотеку. Это разумеется, тоже можно сделать руками, но вы скорее застрелитесь, чем будете после каждого изменения все перчечисленные действия производить руками!

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

Замечательно, мы написали библиотеку, в ней использовали Maven либо гредл, которые нам как минимум все скомпилировали и упаковали в JAR. Супер, у нас есть артифакт. Фактически, этот JAR вы уже можете дать своему товарищу, чтобы тот подключил его к проекту, но это полная дичь, и мы так делать не хотим. Мы хотим, чтобы все было автоматически.

Для этого нам необходимо разместить нашу библиотеку в репозитории. Что же такое этот репозиторий? Помните, вначале я сказал, что Maven придумали множество различных конвенцией? Так вот, репозитории это их рук дело. Физически репозиторий это директория на файловой системе. Т.е. у вас на компе есть «локальный репозиторий». Он есть у всех и создается автоматически. Находится в хоум директории в папке .m2

Вы всегда можете опубликовать ваш JAR в свой локальный репозиторий. Но в чем прикол спросите вы? Как ваш коллега тогда подключит библиотеку в свой проект, если один фиг она только на вашем компе? Все верно - никак. Локальные репозитории нужны для кеширования внешних скачанных библиотек и для отладки своих библиотек.

Оказывается, существуют еще некие «удаленные репозитории» (не от слова delete, а от слова remote). Удаленный репозиторий - это сервер, на котором можно хранить JAR. У него есть определенный API по которому с ним можно взаимодействовать и загружать на него свои библиотеки, и скачивать нужные вам.

Я думаю, вы уже начали догадываться, что тот кто пишет проект и хочет подключить вашу библиотеку к себе, тоже должен собирать свой проект при помощи Maven или Gradle. Эти ребята умеют взаимодействовать как с локальными, так и с удаленными репозиториями и умеют там находить зависимости, которые вам нужны. Для того, чтобы объяснить Maven или Gradle о том, что вам нужно подключить библиотеки (зависимости) к проекту - в специальном конфигурационном файле нужно объявить секцию dependencies в которой вы пишете полное название с версией нужно вам бибилиотеки - groupId, artifactId и version. Да, да, это тоже конвенции Maven.

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