Системы сборки для Java

#java #maven #gradle #ant

Я не совсем понимаю как работает Intellij Idea и как она собирает мою программу.
Можно краткий инструктаж в системы сборки и для чего они нужны?
Ещё бы хорошо, если была бы инфа неустаревшая.
    

Ответы

Ответ 1

TL;DR, к сожалению, не получилось.

Система сборки – это программное обеспечение, обеспечивающее автоматизацию сборки
проекта. Основное отличие от IDE в том, что конфигурационный файл для системы сборки
вы описываете в текстовом виде. Как следствие, быстрее можете начать проект, за счет
того, что что все типовые задачи заключаются в копировании уже готовых сниппетов. Это
гораздо быстрее, более гибко, мобильно, и, главное,  читаемо, чем вводить то же самое
через UI диалоги IDE.

Как в общих чертах работает ваша IDE:


Когда вы создаете проект, то IDE определяет некоторые source каталоги, в которых
находятся исходные файлы вашего проекта. При запуске проекта эти файлы будут скомпилированы
и переместятся в  целевую директорию. Все это, как правило, легко меняется. Можно назначить
дополнительные source каталоги, в которых IDE будет осуществлять поиск исходных файлов
или поменять целевую директорию;
Если ваш проект использует библиотеки, то вы скачиваете их, складываете в определенную
директорию, и подключаете их как зависимости вашего проекта. Таким образом IDE оповещается
о том, что при запуске проекта, эти JAR-файлы будут находиться в classpath, она сама
подставит их в ключ java –cp и начнет предоставлять типы и методы этих библиотек в
автодополнении, и делать другие удобные вещи, для которых и предназначены IDE;
Проекту назначается соответствующая JDK, компилятор которой и будет компилировать классы;
Могут назначаться некоторые дополнительные опции, такие как переменные окружения,
аргументы JVM и прочее;
IDE также может выполнять определенные задачи. Например, не только положить собранный
проект в каталог сборки, или запустить его, но задеплоить его на удаленный сервер;


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

Очевидные недостатки, которые из этого следуют:


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


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

Первым для автоматизации этих задач появился Ant. Это аналог make-файла, а по сути
набор скриптов (которые называются tasks). Ant – это пример императивного стиля описания
сборки проекта. Вы описываете некое действие, например, скомпилировать файлы в директории
проекта:





.. потом , скопировать их рабочую директорию


    



Все примеры из вики.

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

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

Если вы хотите именно пошагового понимания, что делает IDE за ширмой - соберите проект
с помощью Ant.



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

На смену Ant пришел Maven, который не такой гибкий, но значительно сокращает объем
рутинной работы.  Основные особенности:


Конфигурация Maven - это один файл pom.xml; 
Из коробки поддерживаются различные типы сборки: JAR, WAR, EAR;
Введена стандартная структура каталогов для проекта. Это сделано для того, чтобы
по умолчанию вам не нужно было объяснять системе сборки, где лежат исходные файлы,
ресурсы и куда их нужно переместить после компиляции;
Цикл сборки разбит на phases (фазы). Каждая фаза включает в себя определенный стандартный
сценарий, который называется goal (цель) .  Упрощенно, вы указываете до какой фазы
нужно выполнить проект (например, только скомпилировать), и выполняется набор сценариев
связанных указанной и предыдущими фазами build lifecycle. Дополнительные сценарии реализуются
через плагины к Maven;
Поддерживается модульная архитектура проекта. Можно объявлять зависимости между модулями;
Поддерживаются профили. Это возможность, которая позволяется выполнять сборку проекта
 для различных окружений (машин) по-разному. Например, в профиле для разработки приложения
определяются настройки и плагины, которых нет в профиле для продакшена, и наоборот.
Т.е. можно, например, иметь разные настройки для подключения к базе данных для рабочей
машины и сервера, где будет разворачиваться приложения. Или добавить профиль для развертывания
среды окружения, который содержит только плагины и скрипты, которые подготовят ваше
рабочее место при переезде с места на место. Название профиля передается как опция
(ключ -P) к сборке проекта;
Для централизованного хранения библиотек введен центральный репозиторий. Все популярные
библиотеки публикуются и периодически обновляются в центральном репозитории. Каждая
библиотека уникально идентифицируется по параметрам: groupId, artifactId, version.
Вам не нужно скачивать зависимости и хранить их где-то вместе с проектом, они объявляются
декларативно в теге dependency и скачиваются автоматически при сборке проекта. 


Maven выполняет автоматическое разрешение зависимостей (так называются библиотеки,
от которых зависит ваше приложение). Таким образом, например, если библиотека A зависит
от библиотеки C, и библиотека B зависит от библиотеки C, но эти C – разных версий,
Maven автоматически включит в проект только последнюю версию C (иногда это минус, но
все настаивается). Также просто, например, проверить не появились ли новые версии для
библиотек, входящих в состав проекта:

mvn versions:display-dependency-updates

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


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


Для Maven есть огромное число полезных плагинов. Основной недостаток, которым ему
обычно пеняют, вытекает из его преимуществ. Декларативный стиль описания задач не позволяет
так же просто “подшаманить” в определенных случаях, как это делает Ant. Но и это обычно
 решается через через различные плагины. Например, задачм Ant можно запускать из Maven
через antrun-plugin.

Нужно отметить, что когда вы работаете с Maven проектом в IDE, настройки извлекаются
именно из Maven. Например, через compiler-plugin проекту указывается версия JDK:


    org.apache.maven.plugins
    maven-compiler-plugin
    
        1.7
        1.7
    



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

За Gradle не скажу, потому что игрался, но вплотную не использовал.

Резюме: если вы учитесь или делаете тестовый проект без зависимостей на час - IDE
нормальный вариант - хотя сейчас все туториалы тоже пишутся под Maven или Gradle. Для
остального - система сборки.



Обновление:

Как вам правильно указал @Arsenicum, проект можно собрать и без участия IDE и систем
сборки. JDK (Java Development Kit), которое необходимо для разработки, как раз и состоит
из виртуальной Java машины (JRE) - это среда исполнения или рантайм, и Development
Tools - это инструменты среды разработки.

Development Tools - это набор, в основном, консольных утилит. Они находятся в директории
$JAVA_HOME/bin. Полный список тут. Умение напрямую работать с утилитами из набора Basic
Tools (особенно jar, java, javac, javadoc), несомненно поможет лучше ориентироваться
в вопросах запуска и сборки Java приложений.


Ответ 2

Главная особенность, когда вы используете ant, gradle или maven, что сборка вашего
продукта - это тоже код и вы им управляете как кодом и он хранится вместе с исходниками
вашей программы.

Т.б. для воспроизведения всех шагов по сборке проекта достаточно установить систему
сборки и получить код вашего проекта (git, svn) - после этого одна команда и ваш проект
собран, а иногда даже и запущен, а еще лучше если протестирован и задеплоин.

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

Отсюда вывод - используйте всегда gradle ) и посмотрите еще в сторону Docker и такого
понятия, как инфраструктура как код - это просто дальнейшее развитие этой идеи - все
хранить в виде кода.