При изучении любого языка программирования и написании учебных программ достаточно только среды разработки, где код можно скомпилировать и запустить, но для промышленных проектов нужно обязательное знание систем сборщиков. В этой статье разберемся, зачем они вообще нужны и какие существуют для Java.
Зачем нужна система сборки
Когда компьютеры только начинали свое существование, системы сборки не были нужны, программы писались под определенные ЭВМ. С развитием индустрии серверы для разработки отделились от промышленных(“продакшен”) серверов, на которых разработанные приложения должны были использоваться.
Вы можете запускать приложения в среде разработки, но тогда вам понадобится установить ее на все компьютеры заказчика, разложить исходные коды по нужным папкам, установить все требуемые библиотеки и так далее. Очевидно, что это неудобно.
Поэтому и появились системы сборки: они не зависят от IDE и автоматически выполняют действия, перечисленные выше.
Какие бывают системы сборки
Система сборки — это скриптовый код, написанный обычно на определенном языке программирования. Следовательно, для каждого языка они разные. Большинство основаны на самом первом сборщике — Linux-утилите make. Она использует специальные make-файлы, в которых подробно расписаны зависимости файлов друг от друга и порядок их сборки. Этот подход появился еще в 1976 и использовался всеми языками программирования, в том числе Java до разработки собственного средства.
Давайте узнаем подробнее о сборщиках Java.
Первым из них был Apache Ant (Another neat tool). По схеме работы очень похож на утилиту make, но вместо make-файла, состоящего из команд Bash, использует файл формата XML. Вот пример build.xml файла для простого проекта “Hello World”.
Фазы сборки называются целями (). В этом файле их 4: clean, compile, jar и run. Например, при вызове
Сначала отработает clean, который удалит каталог «classes». После этого compile заново создаст каталог, который скомпилируется в папку src, все как определил разработчик. И вообще, поскольку Ant не навязывает никаких соглашений о структуре проекта, программисты сами пишут все команды и определяют порядок сборки.
Что не так?
Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. Здесь все выглядит неплохо, но на промышленный проектах они длинные и неструктурированные, а потому сложны для понимания.
Что привело к появлению новой системы
Apache Maven
Хоть он также использует XML для построения конфигурации (файл называется POM.xml), но имеет серьезные отличия:
1. Здесь есть четкая структура каталогов, и вы обязательно должны ей следовать. (При использовании плагинов IDE, она создается автоматически).Она выглядит вот так:
И если вы, к примеру, поместите файл с тестами в папку с ресурсами, то ваше приложение просто не скомпилируется.
Также у каждого проекта может быть только один файл JAR файл, тогда как при сборке Ant модификации были безграничны: вы вообще можете добавить файл в какую угодно папку, собрать 5 классов в 3 JAR-а и так далее. Все это, безусловно, ухудшало поддерживаемость кода.
2. Автоматическое управление зависимостями
В промышленных проектах зависимостей очень много. В Ant вы должны все скачать вручную, распаковать, подключить и обязательно помнить, какую вы используете версию. А вот Maven все делает сам, только напишите, что вам нужно.
3. Стандартизированные названия билдов
Каждый билд имеет атрибуты groupId, artifactId и version. Первые два уникальны и используются для определения в репозитории. Обычно groupId — доменное имя организации, а artifactId — название текущего проекта. Поэтому эта пара и является определяющей: нет двух компаний с одинаковым доменом, как и не существует двух одинаковых проектах в одной компании.
4. Жизненный цикл и плагины
Жизненный цикл maven-проекта — это список фаз, определяющий порядок действий при его построении. Он содержит три независимых порядка выполнения: clean, default и site.
Для расширения и модификации стандартных ЖЦ используются плагины. Ниже представлен пример плагина, который копирует зависимости в ваше директорию.
Плагины, хоть и предоставляют программистам дополнительные возможности, но Maven не дает большой свободы модификаций. Программисты решили взять лучшее из двух миров и разработали Gradle.
Gradle
Оба, и Ant, и Maven используют XML для конфигурирования сборки. Gradle — предметно-ориентированный язык на основе Groovy. И это его основное отличие от Maven. В остальном Gradle руководствуется теми же принципами. Здесь за выполнение всей работы также ответственны плагины и нет широкой свободы действий.
Приведем пример файла build.gradle для того же проекта с HelloWorld
Gradle распространен в мобильной Android- разработке, а Maven используется в системах управления предприятиями. Почему так? Вопрос остается открытым. Возможно, так просто сложилось. Но Maven все-таки гораздо популярнее на рынке и будет полезен Java-разработчикам в любом случае.
Build Systems — Intro
Данный пост будет об автоматических системах сборки. Думаю, интуитивно понятно что это и зачем нужно, но для формальности написать нужно — это такие программные продукты, которые на основе некоторой конфигурации могут «собрать» ваш проект. Под словом «собрать» здесь может скрываться очень обширный объем работы, который при «ручном» подходе требует значительных затрат времени.
загрузить зависимые библиотеки для вашего проекта из сети (репозитория);
скомпилировать классы модуля или всего проекта;
сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
удалять/создавать директории и копировать в них указанные файлы;
упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
установка (deploy) файлов проекта на удаленный сервер;
генерация документации и отчетов.
Путаница
На хабре есть ряд статей о Maven, но, к сожалению, все они находятся в разных хабах, т.к. отдельного хаба для билд систем не существует. Поэтому, я решил «не быть как все» и выбрать именно общий хаб «Программирование», а не «Java», «Веб-разработка» и др.
Поэтому не заинтересованный читатель может продолжить свой поиск интересного, а заинтересованный — читать далее.
Я специально начал пост с пояснений и описания возможностей, так как данные системы могут делать сборки не только для «Java» и применимы не только в веб-разработке. Возможности и варианты использования данных систем значительно шире.
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё время.
High-level архитектура
конфигурации
собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
На этом общую часть о build-системах закончу и перейду к более конкретным вещам.
Maven
Так как переписывать то, что написали другие было бы неправильно, поэтому приведу перечень статей по теме, которые уже есть на хабре о Maven и где описано конкретно об этой системе — что это, как работает и на каких принципах основана.
Maven — зачем? — вводная статья о Maven, где описано как устроена конфигурация модуля/проекта, жизненный цикл сборки.
Apache Maven — основы — терминология, установка, сборка, создание проекта из архетипа, полезные ссылки
Maven — автоматизация сборки проекта — более детальное описание жизненного цикла сборки, описание настроек диплоя (deploy), на примере установки для Tomcat сервера.
Создание своих архетипов и каталогов в Maven — для людей уже «в теме» и желающих создавать свои архетипы, если по каким-то причинам не хватает существующих. Процесс описан довольно детально.
Заключение
Целью данной статьи было донести до читателя информацию о системах сборки в целом, зачем они нужны и какие задачи способны выполнять. На этом откланиваюсь и надеюсь, что данная статья найдет своего читателя, который не побоится использовать подобные системы для своих повседневных задач, и покажет простоту и эффективность систем сборки проектов.
Системы сборки для Java
Я не совсем понимаю как работает Intellij Idea и как она собирает мою программу. Можно краткий инструктаж в системы сборки и для чего они нужны? Ещё бы хорошо, если была бы инфа неустаревшая.
Отслеживать
задан 23 фев 2016 в 22:31
Dark Casual Dark Casual
136 1 1 серебряный знак 8 8 бронзовых знаков
А вы для начала попробуйте разработать небольшую программу (типа «Hello world») и собрать проект вручную без IDE. Крайне рекомендую так сделать. Вам это поможет разобраться.
24 фев 2016 в 6:04
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
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 – это пример императивного стиля описания сборки проекта. Вы описываете некое действие, например, скомпилировать файлы в директории проекта:
.. потом , скопировать их рабочую директорию
" includes="**/*.*" excludes="**/*.java"/>
И вот из таких маленьких кирпичиков, поэтапно собираете весь сценарий сборки проекта. А точнее, несколько сценариев для разных целей. Написав единожды хороший универсальный сценарий, можно копировать его в последующие проекты.
Удобно в 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 (иногда это минус, но все настаивается). Также просто, например, проверить не появились ли новые версии для библиотек, входящих в состав проекта:
Поскольку зависимости выкачиваются автоматически, очень удобно делить проект между участниками команды. Предположите, как-бы вы управляли большим числом зависимостей вручную;
Maven поддерживает архетипы. Это предопределенная структура проекта (шаблон) для быстрого начала разработки приложения. При создании проекта вы можете указать архетип, и вот уже есть некая начальная заготовка. Естественно, можно создавать собственные.
Для Maven есть огромное число полезных плагинов. Основной недостаток, которым ему обычно пеняют, вытекает из его преимуществ. Декларативный стиль описания задач не позволяет так же просто “подшаманить” в определенных случаях, как это делает Ant. Но и это обычно решается через через различные плагины. Например, задачм Ant можно запускать из Maven через antrun-plugin.
Нужно отметить, что когда вы работаете с Maven проектом в IDE, настройки извлекаются именно из Maven. Например, через compiler-plugin проекту указывается версия JDK:
Все 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. Используйте автоматические системы сборки программ
Нажимайте на одну (единственную) кнопку: используйте полностью автоматизированные («в одно действие») системы, которые собирают весь проект без вмешательства пользователя.
Процесс сборки программы «в одно действие» очень важен. Он должен давать надежный и воспроизводимый результат трансляции ваших исходных файлов в распространяемый пакет. Имеется богатый выбор таких автоматизированных инструментов сборки, так что нет никакого оправдания тому, что вы их не используете. Выберите один из них и применяйте его в своей работе.
Мы встречались с организациями, где подобное требование игнорировалось. Некоторые полагают, что настоящий процесс сборки должен состоять в том, чтобы пощелкать мышью там и сям, запустить пару утилит для регистрации серверов COM/CORBA и вручную скопировать несколько файлов. Вряд ли у вас есть лишнее время и энергия, чтобы растрачивать их на то, что машина сделает быстрее и лучше вас. Вам нужна надежная автоматизированная система сборки программы «в одно действие».
Успешная сборка должна происходить молча, без каких бы то ни было предупреждений (см. рекомендацию 1). Идеальный процесс сборки должен выдать только одно журнальное сообщение: «Сборка успешно завершена».
Есть две модели сборки — инкрементная и полная. При инкрементной сборке компилируются только те файлы, которые претерпели изменения со времени последней инкрементной или полной сборки. Следствие: вторая из двух последовательных инкрементных сборок не должна перезаписывать никакие файлы. Если она это делает — по всей видимости, у вас в проекте имеется циклическая зависимость (см. рекомендацию 22), либо ваша система сборки выполняет ненужные операции (например, создает фиктивные временные файлы, чтобы затем просто удалить их).
Проект может иметь несколько видов полной сборки. Рассмотрите возможность параметризации процесса сборки при помощи таких важных параметров, как целевая архитектура, отладочная или коммерческая версии, вид пакета (программа-инсталлятор или просто набор файлов). Одни установки сборки могут давать только наиболее существенные исполнимые и библиотечные файлы, другие — добавлять к ним вспомогательные файлы, а окончательная сборка — создавать программу-инсталлятор, которая включает в себя все ваши файлы, файлы сторонних производителей и код инсталляции.
Со временем размер проекта обычно возрастает, растет и стоимость отказа от автоматизированной системы сборки. Если вы не используете ее с самого начала, вы теряете время и ресурсы. Все равно со временем потребность в такой системе станет непреодолимой, но при этом вы окажетесь под гораздо большим давлением, чем в начале проекта.
В больших проектах возможна даже специальная должность «хозяина сборки», который отвечает за работу этой системы.
4. Пакеты (сборки) системы Tor Программное обеспечение Tor разрабатывается для различных операционных систем: — ОС семейства Microsoft Windows — ОС семейства Linux/Unix- ОС Apple- и для смартфонов (ОС Android, iPhone, iPad и др.)Для каждой из операционных систем существуют различные варианты
6.2. Работа со службами с помощью программ операционной системы
6.2. Работа со службами с помощью программ операционной системы Естественно, что со службами можно работать не только с помощью реестра , но и используя специальные стандартные программы операционной системы Windows Vista. Одну из таких программ мы уже рассмотрели. Это оснастка
Приложение Б. Общие параметры программ для системы X Window
Приложение Б. Общие параметры программ для системы X Window Каждая программа, предназначенная для работы в системе X Window, имеет параметры, представленные в табл. Б.1.Параметры программ X Window Таблица Б.1 Параметр Описание -background <red|green|blue> Устанавливает цвет фона -background
Вариант 1 – Автоматические тексты
Вариант 1 – Автоматические тексты Есть полуавтоматические способы создания текстовой информации. Их плюс в том, что для Google и Яндекс они будут уникальными Это быстро и относительно недорого Здесь вы берете количеством. Минус – контент получится достаточно «мусорным» и
Автоматические транзакции
Автоматические транзакции Для разрешения провайдеру самостоятельно управлять транзакциями нужно указать в строке инициализации параметр «auto_commit=true»:Call сn.Open(«data source=localhost:d:databaseemployee.gdb;auto_commit=true»,»gamer», «vermut»)В этом случае все создаваемые объекты сессий для данного источника
Автоматические отступы
Автоматические отступы Чтобы до минимума уменьшить объем выполняемой вами работы, редактор Visual Basic автоматически устанавливает отступ в новой строке, равный отступу в предыдущей. Если в новой строке отступ должен быть меньше, просто нажмите клавишу удаления символа
Автоматические переменные
Автоматические переменные По умолчанию переменные, описанные внутри функции, являются автоматическими. Можно, однако, это подчеркнуть явно с помощью ключевого слова auto:main( )
8.3.1. Автоматические объекты
8.3.1. Автоматические объекты Автоматический объект размещается в памяти во время вызова функции, в которой он определен. Память для него отводится из программного стека в записи активации функции. Говорят, что такие объекты имеют автоматическую продолжительность
8.3.2. Регистровые автоматические объекты
8.3.2. Регистровые автоматические объекты Автоматические объекты, интенсивно используемые в функции, можно объявить с ключевым словом register, тогда компилятор будет их загружать в машинные регистры. Если же это невозможно, объекты останутся в основной памяти. Индексы
Автоматические индексы в сравнении с определенными пользователем индексами
Автоматические индексы в сравнении с определенными пользователем индексами Firebird автоматически создает индексы для обеспечения различных ограничений целостности (более подробную информацию см. в главах 16 и 17). Для удаления таких индексов необходимо удалить
Выбор дополнительных программ и компонентов системы
Выбор дополнительных программ и компонентов системы После того как разметка диска окончена, программа установки может спросить, какие дополнительные программы или компоненты системы нужно устанавливать, а какие нет. Здесь возможны следующие варианты.Если вы
6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ
6.2. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ ПРОГРАММ Программная система может состоять из отдельных разработанных разными организациями выполняемых программ. Объединение функций этих программ в целую единую программу может привести к нехватке оперативной памяти машины, а сама
6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ
6.3. СИСТЕМЫ ИЗ ОТДЕЛЬНЫХ РЕЗИДЕНТНЫХ ПРОГРАММ Резидентная программа — программа, которая постоянно находится в оперативной памяти машины и не препятствует запуску новых программ. После запуска резидентная программа становится как бы частью операционной системы MS DOS
6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ
6.4. СИСТЕМЫ ИЗ ПРОГРАММ, ОБМЕНИВАЮЩИХСЯ ДАННЫМИ ЧЕРЕЗ ПОРТЫ Такой обмен обычно реализуется при многопроцессорной (многомашинной) обработке. Порт каждой из программ представляет программу накопления и верификации как входных, так и выходных данных в соответствующих
