Страницы

Поиск по вопросам

среда, 19 декабря 2018 г.

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

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


Ответ

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 приложений.

Комментариев нет:

Отправить комментарий