Зачем нужны системы сборки java-приложений.

Когда я только начинал свою карьеру программиста, я долго не мог понять зачем нужны системы сборки проекта, такие как Maven или Gradle. Что неудивительно, так как до того как меня взяли на первую работу я имел смутное представление о том, что такое зависимости и деплоймент. Как сейчас помню, в (уже устаревшей) книге Head First Servlets and JSP было упоминание о development структуре проекта и о итоговом веб-архиве (то что сейчас называется артефакт). А еще в этой книге описывалась ручная компиляция и архивирование проекта. Я собственноручно собирал проект в консоли и создавал war-файл, что, будь я поумнее, могло бы натолкнуть на мысль о существовании автоматических инструментов сборки.

В общем, представим что нам нужно написать веб-приложение на Java. Что это приложение будет собой представлять? Скорее всего это будет war-архив с определенной структурой подпапок. Ну а в папках будут содержаться скомпилированные классы, файлы конфигурации, JavaScript файлы, каскадные таблицы стилей, html темплейты, в общем, все что составляет наше веб-приложение. И теперь вопрос - откуда у нас вообще возьмется этот архив? Со статическими ресурсами вроде все ясно - создаем каталог, раскидываем по подпапкам CSS, JS и HTML файлы и архивируем, но как быть с классами?

Итак, допустим у нас в веб-приложении есть несколько классов, например сервлетов. Чтобы получить .class файлы нам нужно скомпилировать эти классы с помощью консольной команды javac написав что-то вроде:

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

Чтобы как-то автоматизировать эту рутину и были придуманы системы сборки. Появлялись они в таком порядке: сначала Ant, потом Maven, потом Gradle (на самом деле их больше, но в мире Java эти - самые популярные). Если говорить совсем просто, основная задача системы сборки - это компилировать и упаковывать. Архив, получившийся в результате сборки называется артефактом. Этот артефакт представляет собой либо готовое приложение, либо библиотеку, которую можно будет использовать уже в другом проекте.

Сама по себе, система сборки - это консольное приложение. Чтобы его использовать, нужно создать файл конфигурации сборки проекта (билд-файл) и запустить из консоли команду (gradle build для Gradle или mvn для Maven) Вот так:

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

Настало время поговорить об еще очень важной функции систем сборки - Управлении Зависимостями. В настоящее время ни одно мало-мальски серьезное приложение на Java не пишется без использования сторонних библиотек. Java-библиотека - это JAR архив, который содержит в себе скомпилированные библиотечные классы. JAR-файл скачивается из интернета и подключается к проекту. Это можно сделать вручную, вот только я гарантирую, вы задолбаетесь нужные библиотеки искать, скачивать и засовывать их в classpath. Поэтому умные дядьки придумали менеджеры зависимостей (dependency manager). Суть их работы проста - в файле, описывающем конфигурацию сборки (pom.xml для Maven или build.gradle для Gradle) мы записывает какие сторонние библиотеки (зависимости) нам нужны и во время сборки система их скачивает, подставляет в classpath и компилирует уже вместе с ними. Скачиваются библиотеки из публичного репозитория (для Java сейчас основной репозиторий - https://mvnrepository.com).

Зависимость (библиотеку) Google Guice в Gradle мы добавим вот так:

compile group: 'com.google.inject', name: 'guice', version: '4.1.0'

И вот так в Maven:

<dependency>
    <groupId>com.google.inject</groupId>
    <artifactId>guice</artifactId>
    <version>4.1.0</version>
</dependency>

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

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

183