Системы сборки
Что это и зачем
На самом низком уровне сборка приложений на Java выглядит так: вы вызываете компилятор, консольную программу javac идущую в составе JDK, передавая ей на вход ваши исходные тексты в .java файлах. Компилятор их компилирует в бинарные .class файлы. Затем эти .class файлы можно уже передать виртуальной машине java, которая их исполнит.
В случае простейшего тестового приложения из одного файла, вы можете всю эту цепочку действий сделать самостоятельно, используя туториал наподобие https://javarush.ru/groups/posts/2318-kompiljacija-v-java. Однако очень быстро такой подход перестает работать. Как только в вашем приложении появляются десятки и сотни классов и множество внешних зависимостей, сборка вручную начинает занимать слишком много времени.
Тут-то и появляются системы сборки, автоматизирующие этот процесс.
Теперь все что вам надо сделать - это в некотором формате описать структуру вашего приложения. Что вот тут лежат исходные коды, тут - ресурсы, собрать это все надо в архив такого формата, подключив такие зависимости. Дальше вы запускаете систему сборки, передав ей ваш файл с описанием структуры, и остальное она делает сама:
Найдет ваши .java файлы
Скачает необходимые библиотеки
Все это передаст компилятору javac
Результат упакует как надо в .jar архив или иной формат
Опционально - прогонит тесты, загрузит результат сборки куда-нибудь по сети, отправит оповещения о результатах по почте и т.п.
Управление зависимостями
Одним из самых важных и полезных плюсов таких систем можно назвать автоматическое управление зависимостями. Вот вам понадобилась в вашей программе работа с геометрией - всякое пересечение многоугольников, плоскостей и тому подобные алгоритмы. Для этого есть популярная библиотека JTS, которую вам надо добавить в свой проект.
При ручной сборке вам бы пришлось скачивать .jar файл вашей библиотеки, класть его в какую-нибудь папочку, затем при каждой сборке добавлять его к командной строке компилятора. При этом сразу встает куча вопросов: где взять этот файл (хорошо, если у библиотеки есть свой личный сайт, где он выложен, а если нет?), какой версии, как его обновлять, где его хранить (зависимости проекта могут занимать сотни мегабайт, и хранить их на каких-то общих сетевых ресурсах может быть нежелательно).
Современные системы сборки решают этот вопрос. Существуют онлайн-репозитории, в которые уже выложено очень много различных библиотек, например Maven Central (созданный изначально для работы с системой сборки Maven). Все что вам нужно - найти репозиторий, в котором есть нужная вам библиотека, затем в своем скрипте сборки указать ее название и версию. И все. Дальше система сборки сама сходит в интернет, найдет в репозитории нужный .jar файл, скачает и подключит к проекту.
Искать нужные вам библиотеки удобно на сайте https://mvnrepository.com - это мета-поисковик, индексирующий все самые популярные репозитории для Java.
Репозиторий можно завести и свой собственный. Для этого есть различное ПО, например Sonatype Nexus или JFrog Artifactory. Это веб-сервисы, которые вы можете развернуть на своем сервере и выкладывать туда ваши собственные библиотеки, которые вы используете в разных своих проектах, чтобы не таскать .jar файлы между проектами вручную.
История систем сборки в Java
В Java исторически можно выделить три основных поколения систем сборки.
Apache Ant
https://ru.wikipedia.org/wiki/Apache_Ant
Самая старая из ныне живущих систем. Сейчас встречается только в старых легаси-проектах.
Структура проекта задается в XML
Изначально был исключительно инструментом автоматизации сборки и не имел встроенного менеджера зависимостей. Позднее под него для этих целей был разработан Apache Ivy, но время уже ушло.
Apache Maven
https://ru.wikipedia.org/wiki/Apache_Maven
Эта система сборки оказалась такой удачной, что жива до сих пор. Именно под нее были созданы большинство онлайн репозиториев с библиотеками, и другие системы сборки используют эту инфраструктуру.
Структура проекта так же задается в виде XML, с именем pom.xml. XML формат это и плюс, и минус. С одной стороны, описывать проекты достаточно легко. С другой - как только вам нужны хоть немного нетривиальные шаги сборки, вам приходится писать свой собственный вид XML тегов и свой плагин для Maven, который будет их обрабатывать.
Gradle
Наиболее актуальная на данный момент система сборки, все новые проекты рекомендую делать именно на ней.
В отличие от Ant и Maven, для описания проекта она использует не XML, а скрипты на языке Groovy. Так что если вам нужна сложная логика сборки - прямо в сборочном скрипте вы можете писать классы, методы и любую логику, которая потребуется.
Из Gradle вы можете легко использовать инфраструктуру репозиториев Maven и иметь доступ ко всем выложенным там библиотекам.
Чуть более детальный обзор можно найти в статье https://www.baeldung.com/ant-maven-gradle
А вот раньше из IDE собирали, безо всяких ваших мавенов
Многие популярные IDE могут сами хранить струткуру проекта в своих файлах (для Intellij Idea это .iml и .ipr файлы) и сами выполнять сборку. И долгое время такой формат был популярен. Однако постепенно появилось понимание, что IDE как редактор кода стоит отделить от собственно системы сборки.
Крупные проекты часто приходится собирать из командной строки, на специальном билд-сервере. Существуют системы автоматизации тестирования, когда ваш код автоматически собирается и тестируется после каждого изменения. Для таких целей не нужен сам интерфейс IDE, все что им нужно - это возможность выполнить консольную команду и получить собранный проект.
Файлы проекта, которыми оперирует IDE, часто содержат слишком много локальных настроект. Всякие там стили интерфейса, наборы окошек-менюшек, локальные пути к папкам со сторонними SDK. Использовать такие файлы совместно стало затруднительно.
В итоге с годами систему сборки отделили от редактора. И сейчас Idea по умолчанию собирает проекты тем же Gradle, хотя для совместимости еще осталась возможность собирать и встроенной в саму Idea системой сборки. При этом вместе с исходными кодами достаточно распространять только скрипт Gradle, а файлы настроек самой IDE каждый разработчик может хранить у себя сам, для сборки проекта они уже не нужны.
Выводы
Итак, системы сборки в Java:
Автоматизируют и упрощают процесс сборки проекта из кучи файлов
Управляют зависимостями, сами скачивают нужные библиотеки
Отделяют настройку сборки от настроек редактора кода
Рекомендую использовать их во всех своих проектах, даже в простых. И как самую актуальную - использовать Gradle.
Документации по Gradle много, как на официальном сайте https://docs.gradle.org/current/userguide/userguide.html так и на том же Хабре https://habr.com/ru/post/458046/ или в других местах https://javarush.ru/groups/posts/2126-kratkoe-znakomstvo-s-gradle
Gradle за последние десять лет прошла большой путь, и там несколько раз серьезно ломали совместимость в сборочных скриптах при крупных обновлениях. Так что обращайте внимание на дату туториалов и уроков, или на версию Gradle (на момент написания этого текста актуальные версии 6-7).
Last updated