2nd begin
This commit is contained in:
parent
3e1f0389cd
commit
bd03b9d5a1
BIN
build/j-spec.pdf
BIN
build/j-spec.pdf
Binary file not shown.
Binary file not shown.
|
|
@ -21,13 +21,8 @@
|
|||
\newpage
|
||||
%\chapter{Java Core}
|
||||
\subfile{jtc1-1a}
|
||||
|
||||
\section{Управление проектом: сборщики проектов}
|
||||
Управление проектом: Jar-файлы; Gradle/Maven: зависимости, выгрузка артефакта, публичные репозитории, свойства проекта, приватные репозитории (хостинг); Bazel
|
||||
\subsection*{Задания к семинару}
|
||||
\begin{itemize}
|
||||
\item Создать загружаемый артефакт с функцией суммирования двух чисел и загрузить его в локальный кэш артефактов;
|
||||
\end{itemize}
|
||||
\newpage
|
||||
\subfile{jtc1-2a}
|
||||
|
||||
\section{Специализация: данные и функции}
|
||||
Базовые функции языка: математические операторы, условия, циклы, бинарные операторы; Данные: типы, преобразование типов, константы и переменные (примитивные, ссылочные), бинарное представление, массивы (ссылочная природа массивов, индексация, манипуляция данными); Функции: параметры, возвращаемые значения, перегрузка функций;
|
||||
|
|
|
|||
|
|
@ -393,7 +393,7 @@ Here is your number: 4.
|
|||
\end{itemize}
|
||||
\end{enumerate}
|
||||
|
||||
\subsection{Собери его, если сможешь (Makefile, Docker)}
|
||||
\subsection{Автоматизируй это (Makefile, Docker)}
|
||||
В подразделе \hrf{subsec:cli} мы проговорили о сборке проектов вручную. Компилировать проект таким образом — занятие весьма утомительное, особенно когда исходных файлов становится много, в проект включаются библиотеки и прочее.
|
||||
|
||||
\begin{frm}
|
||||
|
|
@ -415,7 +415,7 @@ all:
|
|||
\item SRCDIR := src
|
||||
\item OUTDIR := out
|
||||
\end{itemize}
|
||||
И далее вызывать их (то есть подставлять ихзначения в нужное место текста) следующим образом:
|
||||
И далее вызывать их (то есть подставлять их значения в нужное место текста) следующим образом:
|
||||
\begin{lstlisting}[style=ASMStyle]
|
||||
javac -sourcepath .${SRCDIR}/ -d ${OUTDIR}
|
||||
\end{lstlisting}
|
||||
|
|
|
|||
|
|
@ -0,0 +1,208 @@
|
|||
\documentclass[j-spec.tex]{subfiles}
|
||||
|
||||
\begin{document}
|
||||
\section{Управление проектом: сборщики проектов}
|
||||
\subsection{В предыдущих сериях...}
|
||||
В прошлом разделе мы рассмотрели:
|
||||
\begin{itemize}
|
||||
\item краткую историю;
|
||||
\item что скачать, и как это выбирать;
|
||||
\item какие шестерёнки крутятся внутри;
|
||||
\item структуру простого и обычного проекта;
|
||||
\item стандартную утилиту для создания документации;
|
||||
\item сторонние инструменты автоматизации сборки.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{В этом разделе}
|
||||
Будет коротко рассмотрена мотивация создания и использования сборщиков проектов (зачем это нужно), какой эволюционный путь прошли специализированные сборщики проектов, какие новые понятия появились при их использовании. Рассмотрим два самых популярных на сегодняшний день сборщика и один экзотический, но достаточно быстро набирающий обороты. Поймём какой путь проделывает чужая библиотека, чтобы попасть в наш проект и научимся публиковать собственный код, делая тем самым вклад в сообщество.
|
||||
\begin{itemize}
|
||||
\item \nom{Ant}{Apache Ant (англ. ant — муравей и акроним — «Another Neat Tool») — утилита для автоматизации процесса сборки программного продукта. Является кросс-платформенным аналогом утилиты make, где все команды записываются в XML-формате.}
|
||||
\item \nom{Ivy}{Apache Ivy переходный пакетный менеджер. Является подпроектом Apache Ant, которому нужен для разрешения зависимостей. Внешний XML файл определяет зависимости проекта и перечисляет ресурсы, необходимые для сборки проекта. Ivy ищет и скачивает ресурсы из репозитория (приватного или публичного).};
|
||||
\item \nom{Maven}{Apache Maven — фреймворк для автоматизации сборки проектов на основе описания их структуры в файлах на языке POM (англ. Project Object Model), являющемся подмножеством XML. В отличие от Ant, декларативный. Проект Maven издаётся сообществом Apache Software Foundation. Название системы является словом из языка идиш, смысл которого можно примерно выразить как «собиратель знания».};
|
||||
\item \nom{Gradle}{система автоматической сборки, построенная на принципах Apache Ant и Apache Maven, но предоставляющая специалььный предметно-ориентированный диалект на языках Groovy и Kotlin вместо традиционной XML-образной формы представления конфигурации проекта.};
|
||||
\item \nom{Bazel}{свободный программный продукт для автоматизации сборки и тестирования приложений. Компания Google использует внутренний инструмент под названием Blaze, и выпустила свободно распространяемый вариант с открытым исходным кодом под названием Bazel (анаграмма Blaze). Bazel впервые выпущен в марте 2015.};
|
||||
\item \nom{Артефакт}{Артефакт — это любой созданный искусственно элемент программной системы. К элементам программной системы, а, следовательно, и к артефактам, могут относиться исполняемые файлы, исходные тексты, веб страницы, справочные файлы, сопроводительные документы, файлы с данными, модели и многое другое, являющееся физическим носителем информации.};
|
||||
\item \nom{Репозиторий}{место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети};
|
||||
\item \nom{Прокси}{промежуточный комплекс, выполняющий роль посредника между пользователем и целевым сервером, позволяющий клиентам как выполнять косвенные запросы к другим сетевым службам, так и получать ответы. Сначала клиент подключается к прокси и запрашивает какой-либо ресурс (например артефакт), затем прокси либо подключается к указанному серверу и получает ресурс у него, либо возвращает ресурс из собственного кэша.};
|
||||
\end{itemize}
|
||||
|
||||
\subsection{Мотивация и схема (зачем это нужно и как это работает)}
|
||||
Сборщие проекта - это сложный инструментарий, который может скрывать обширный объем работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным.
|
||||
|
||||
Позвляют не привязываться к конкретным IDE и интерфейсу среды разработки. Имеют текстовое управление, что часто ускоряет процесс работы с ними на пред-продакшн серверах, где часто терминальный интерфейс.
|
||||
|
||||
\begin{frm}
|
||||
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборки ничего не знает, то есть является инструментом более широкого спектра.
|
||||
\end{frm}
|
||||
|
||||
Сборщик часто решает целый спектр задач, для решения которых компилятор не предусмотрен. Например:
|
||||
\begin{itemize}
|
||||
\item загрузить зависимые библиотеки;
|
||||
\item скомпилировать классы модуля;
|
||||
\item сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и пр.;
|
||||
\item упаковать скомпилированные классоы в архивы;
|
||||
\item компилировать и запустить модульные тесты и рассчитать процент покрытия;
|
||||
\item развернуть (deploy) файлы проекта на удаленный сервер;
|
||||
\item генерировать документацию и отчеты.
|
||||
\end{itemize}
|
||||
|
||||
Системы сборок имеют схожую верхнеуровневую архитектуру:
|
||||
\begin{enumerate}
|
||||
\item Конфигурации - собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
|
||||
\item Конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
|
||||
\item Парсеры конфигураций - парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
|
||||
\item Парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
|
||||
\item Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
|
||||
\item Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
|
||||
\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
|
||||
\end{enumerate}
|
||||
|
||||
Для языка Java основных систем сборок три:
|
||||
\begin{itemize}
|
||||
\item Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy, в чистом виде Ant почти никогда не применялся;
|
||||
\item Самый популярный инструмент - это Maven, используется для JavaEE и приложений с использованием Spring Framework;
|
||||
\item Gradle основной инструмент в мобильной разработке, часто Groovy/Kotlin описания сборки оказываются удобнее XML;
|
||||
\end{itemize}
|
||||
|
||||
Экзотическая Bazel. Её отличает полная кроссплатформенность и кросстехнологичность, что делает её особенно привлекательной для микросервисных проектах, использующих несколько языков программирования.
|
||||
|
||||
\subsection{С чего всё начиналось (Ant, Ivy)}
|
||||
Первый специализированный инструмент автоматизации задач для языка Java. По сути, это аналог \code{Makefile}, то есть набор скриптов (которые в разговорной речи называются тасками\footnote{от англ task - задача, задание}). В отличие от make, утилита Ant имеет только одну зависимость — JRE. Ещё одним важным отличием от мейка является отказ от использования команд операционной системы. Всё что пишется в ант пишется на XML, что обеспечивает переносимость сценариев между платформами.
|
||||
|
||||
Управление процессом сборки как только что было сказано, происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (таргетов, с этим понятием мы познакомились когда говорили о мейкфайлах). Цели в терминах ант сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (тасков). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.
|
||||
|
||||
Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере).
|
||||
|
||||
Скачивание и установка, ant для Linux-подобных ОС выполняется привычной командой установки в вашем пакетном менеджере, вроде sudo apt install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив, распаковав его и прописав соответствующий путь в переменные среды. Проверить версию можно командой ant -version
|
||||
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=XML,style=ASMStyle]
|
||||
<?xml version="1.0"?>
|
||||
<project name="HelloWorld" default="hello">
|
||||
<target name="hello">
|
||||
<echo>Hello, World!</echo>
|
||||
</target>
|
||||
</project>
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию хмл, без этого никакой хмл никогда не работает. затем говорим, что наш проект называется приветмир, а собирать по умолчанию для этого проекта надо таргет хелло. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру.
|
||||
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
mkdir hello
|
||||
cd hello
|
||||
ant
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд:
|
||||
|
||||
% --- слайд
|
||||
\begin{verbatim}
|
||||
Buildfile: /home/hello/build.xml
|
||||
|
||||
hello:
|
||||
[echo] Hello, World!
|
||||
BUILD SUCCESSFULL
|
||||
\end{verbatim}
|
||||
% --- конец слайда
|
||||
|
||||
В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.хмл и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name.
|
||||
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=XML,style=ASMStyle]
|
||||
<!-- Очистка -->
|
||||
<target name="clean" description="Removes all temporary files">
|
||||
<!-- Удаление файлов -->
|
||||
<delete dir="${build.classes}"/>
|
||||
</target>
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
В стандартной поставке ant присутствует более 100 заранее созданных заданий, таких как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete
|
||||
|
||||
\subsection{Репозитории, артефакты, конфигурации}
|
||||
\subsection{Классический подход (Maven)}
|
||||
\subsection{Всем давно надоел XML (Gradle)}
|
||||
\subsection{Собственные прокси, хостинг и закрытая сеть}
|
||||
\subsection{Немного экзотики (Bazel)}
|
||||
|
||||
|
||||
|
||||
Ant, Ant+Ivy
|
||||
Первым для автоматизации этих задач появился Ant. Это аналог make-файла, а по сути набор скриптов (которые называются tasks). В отличие от make, утилита Ant полностью независима от платформы, требуется лишь наличие на применяемой системе установленной рабочей среды Java — JRE. Отказ от использования команд операционной системы и формат XML обеспечивают переносимость сценариев.
|
||||
Управление процессом сборки происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (Targets). Цели сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (Tasks). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.
|
||||
Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере).
|
||||
Скачивание и установка, в случае каких-то неисправностей, ant для Linux выполняется командой вроде sudo apt-get install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив.
|
||||
Проверить версию можно командой ant -version
|
||||
Теперь можно написать простой сценарий HelloWorld
|
||||
|
||||
<?xml version="1.0"?>
|
||||
<project name="HelloWorld" default="hello">
|
||||
<target name="hello">
|
||||
<echo>Hello, World!</echo>
|
||||
</target>
|
||||
</project>
|
||||
|
||||
|
||||
Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд:
|
||||
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
$ mkdir hello
|
||||
$ cd hello
|
||||
$ ant
|
||||
Buildfile: /home/hello/build.xml
|
||||
|
||||
hello:
|
||||
[echo] Hello, World!
|
||||
BUILD SUCCESSFULL
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
Теперь нужно бы пояснить, что произошло: система сборки нашла файл сценария с указанным по умолчанию именем build и выполнила цель с именем hello, который указан в теге проекта, с помощью атрибута default со значением hello, а также имя проекта, с помощью атрибута name.
|
||||
В стандартной версии ant присутствует более 100 заданий, такие как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete:
|
||||
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
<!-- Очистка -->
|
||||
<target name="clean" description="Removes all temporary files">
|
||||
<!-- Удаление файлов -->
|
||||
<delete dir="${build.classes}"/>
|
||||
</target>
|
||||
\end{lstlisting}
|
||||
|
||||
На данный момент Ant используют в связке с Ivy, которая является гибким, настраиваемым инструментом для управления (записи, отслеживания, разрешения и отчетности) зависимостями Java проекта.
|
||||
Некоторые достоинства Ivy:
|
||||
|
||||
гибкость и конфигурируемость – Ivy по существу не зависит от процесса и не привязан к какой-либо методологии или структуре;
|
||||
тесная интеграция с Apache Ant – Ivy доступна как автономный инструмент, однако он особенно хорошо работает с Apache Ant, предоставляя ряд мощных задач от разрешения до создания отчетов и публикации зависимостей;
|
||||
транзитивность – возможность использовать зависимости других зависимостей.
|
||||
|
||||
Немного о функциях Ivy:
|
||||
|
||||
управление проектными зависимостями;
|
||||
отчеты о зависимостях. Ivy производит два основных типа отчетов: отчеты HTML и графические отчеты;
|
||||
Ivy наиболее часто используется для разрешения зависимостей и копирует их в директории проекта. После копирования зависимостей, сборка больше не зависит от Apache Ivy;
|
||||
расширяемость. Если настроек по умолчанию недостаточно, вы можете расширить конфигурацию для решения вашей проблемы. Например, вы можете подключить свой собственный репозиторий, свой собственный менеджер конфликтов;
|
||||
XML-управляемая декларация зависимостей проекта и хранилищ JAR;
|
||||
настраиваемые определения состояний проекта, которые позволяют определить несколько наборов зависимостей.
|
||||
|
||||
Apache Ivy обязана быть сконфигурирована, чтобы выполнять поставленные задачи. Конфигурация задается специальным файлом, в котором содержится информация об организации, модуле, ревизии, имени артефакта и его расширении.
|
||||
Некоторые модули могут использоваться по разному и эти различные пути использования могут требовать своих, конкретных артефактов для работы программы. Кроме того, модуль может требовать одни зависимости во время компиляции и сборки, и другие во время выполнения.
|
||||
Конфигурация модуля определяется в Ivy файле в формате .xml, он будет использоваться, чтобы обнаружить все зависимости для дальнейшей загрузки артефактов. Понятие «загрузка» артефакта имеет различные варианты выполнения, в зависимости от расположения артефакта: артефакт может находиться на веб-сайте или в локальной файловой системе вашего компьютера. В целом, загрузкой считается передача файла из хранилища в кеш Ivy.
|
||||
Пример конфигурации зависимостей с библиотекой Lombok:
|
||||
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="org.apache" module="hello-ivy"/>
|
||||
<dependencies>
|
||||
<dependency org="org.projectlombok" name="lombok" rev="1.18.24" conf="build->master"/>
|
||||
</dependencies>
|
||||
</ivy-module>
|
||||
|
||||
|
||||
Его структура довольно проста, первый корневой элемент <ivy-module version="2.0"> указывает на версию Ivy, с которой данный файл совместим. Следующий тег <info organisation="org.apache" module="hello-ivy"/> содержит информацию о программном модуле, для которого указаны зависимости, здесь определяются название организации разработчика и название модуля, хотя можно написать в данный тег что угодно. Наконец, сегмент <dependencies> позволяет определить зависимости. В данной примере модулю необходимо одна сторонняя библиотека: lombok.
|
||||
Однако, у такой системы, как Ant есть и свои минусы: Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. На маленьких проектах выглядит всё достаточно неплохо, но на больших они длинные и неструктурированные, а потому сложны для понимания.
|
||||
Что привело к появлению новой системы - Maven.
|
||||
|
||||
|
||||
\end{document}
|
||||
Binary file not shown.
|
|
@ -2,137 +2,123 @@
|
|||
|
||||
\begin{document}
|
||||
\subsection{В предыдущих сериях...}
|
||||
краткой истории и причинах возникновения язка
|
||||
что нужно скачать, откуда и как это всё выбирать
|
||||
из чего всё состоит
|
||||
изучим простую структуру проекта и способы его запуска
|
||||
коротко рассмотрим утилиту джавадок
|
||||
|
||||
Рассмотрели примитивный инструментарий и базовые возможности платформы для разработки приложений на языке Java.
|
||||
На прошлом уроке мы рассмотрели:
|
||||
\begin{itemize}
|
||||
\item краткую историю и причины возникновения языка;
|
||||
\item что скачать, и как выбирать инструментарий, хотя чаще всего инструментарий выбирает вас, а не вы его;
|
||||
\item какие шестерёнки крутятся внутри и как примерно всё это работает;
|
||||
\item структуру простого и обычного проекта;
|
||||
\item стандартную утилиту для создания документации;
|
||||
\item сторонние инструменты автоматизации сборки, экзотический мейк и очень современный докер.
|
||||
\end{itemize}
|
||||
|
||||
\subsection{На этом уроке}
|
||||
|
||||
Мотивация
|
||||
Ant, Ivy
|
||||
Репозитории, артефакты, конфигурации
|
||||
Maven
|
||||
Gradle
|
||||
Собственные прокси, хостинг и закрытая сеть
|
||||
Немного экзотики: Bazel
|
||||
|
||||
\subsection{Понятия и термины урока}
|
||||
Системы сборки
|
||||
Ant, Ivy
|
||||
Maven
|
||||
Gradle
|
||||
bazel
|
||||
Артефакт
|
||||
Репозиторий
|
||||
прокси
|
||||
поговорим о том, чем же люди ползуются, если мейк экзотический, а докер был с нами не всегда. для этого будет коротко рассмотрена мотивация создания и использования специализированных сборщиков проектов, какой эволюционный путь прошли специализированные сборщики проектов, какие новые понятия появились в программировании на языке джава при их использовании. Рассмотрим два самых популярных на сегодняшний день сборщика и один экзотический, но достаточно быстро набирающий обороты. Поймём какой путь проделывает чужая библиотека, чтобы попасть в наш проект и научимся публиковать собственный код, делая тем самым вклад в сообщество.
|
||||
|
||||
\subsection{Мотивация}
|
||||
Зачем собирать проект без IDE и что такое система сборки?
|
||||
(на предыдущем уроке я говорю, цитирую "для этого достаточно через пробел написать соответствующие ключи компиляции и запуска. Конечно, писать каждый раз эти ключи довольно утомительно и для автоматизации этого процесса придумали сборщики проектов, но всегда круто знать и уметь делать вещи в отсутствие сложного инструментария") эту мысль как раз можно и нужно развить
|
||||
Теперь, научившись выполнять компиляцию и запуск с использованием большого количества ключей, можно приступить к изучению сложного инструментария, который в свою очередь может скрывать очень обширный объем работы, который ручном подходе требует значительных затрат.
|
||||
Можно было бы задать вопрос: "Зачем знать команды, если в IDE всё есть?". Здесь есть несколько нюансов:
|
||||
Итак, зачем собирать проект без IDE, почему нужно использовать специальные инструменты и что такое система сборки?
|
||||
Научившись выполнять компиляцию и запуск с использованием большого количества ключей, можно приступить к изучению сложного инструментария, который в свою очередь может скрывать очень обширный объем работы, который при ручном подходе требует значительных затрат и может оказаться весьма утомительным. Можно было бы задать вопрос: "Зачем знать команды, если в IDE всё есть?". Здесь есть несколько нюансов:
|
||||
|
||||
Как мы упоминали на прошлом уроке существует огромное количество IDE, которые отличаются расположением управляющих кнопок и в принципе своим внешним видом. Если в проекте несколько участников, они все должны использовать одну и ту же IDE и синхронизировать настройки при каждом изменении. То есть, можно запускать приложения в IDE, которую нужно будет поставить на все ПК, разложить исходные коды по нужным папкам, установить все требуемые библиотеки и т.д.;
|
||||
У сред разработки постоянно меняется интерфейс, с каждым обновлением. Помимо этого, тыкать мышкой в кучу разных диалогов долго и неудобно;
|
||||
Как упоминалось на прошлом уроке, существует огромное количество IDE, которые отличаются расположением управляющих кнопок и в принципе своим внешним видом. Если в проекте несколько участников, они все должны использовать одну и ту же IDE, чтобы не запутаться и иметь возможность синхронизировать настройки при каждом изменении. То есть, можно запускать приложения в IDE, которую нужно будет поставить на все ПК, разложить исходные коды по нужным папкам, установить все требуемые библиотеки и т.д.; Есть очень секретная информация о том, что не все программисты в команде (даже очень маленькой) одинаково сильно любят одинаковые наборы инструментов.
|
||||
|
||||
Уметь собирать код без среды разработки — суровая необходимость. Настолько суровая, что для решения этой задачи существует особый класс программного обеспечения, называемого системами сборки.
|
||||
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается она от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборке и её существовании ничего не знает. Если чуть конкретнее, то сборка, помимо компиляции, содержит в себе ещё целый спектр задач, для решения которых компилятор не предусмотрен. Небольшой список задач для понимания:
|
||||
У сред разработки постоянно меняется интерфейс, часто даже с каждым обновлением. Помимо этого, часто оказывается, что мышкой в кучу разных диалогов долго и неудобно, поскольку основной инструмент программиста это всё-таки клавиатура;
|
||||
|
||||
загрузить зависимые библиотеки для вашего проекта из сети (репозитория);
|
||||
скомпилировать классы модуля или всего проекта;
|
||||
сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
|
||||
удалять/создавать директории и копировать в них указанные файлы;
|
||||
упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
|
||||
компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
|
||||
установка (deploy) файлов проекта на удаленный сервер;
|
||||
генерация документации и отчетов.
|
||||
К тому же часто бывает нужно пересобрать приложение после незначительной правки прямо на предпродакшн-сервере, а там вовсе не подключена мышка, поэтому терминальный интерфейс сборщика - это спасение.
|
||||
|
||||
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё время.
|
||||
Уметь собирать код без среды разработки — суровая необходимость. Настолько суровая и важная, что для решения этой задачи существует особый класс программного обеспечения, называемого системами сборки.
|
||||
|
||||
\subsection{Ant, Ivy}
|
||||
\subsection{Репозитории, артефакты, конфигурации}
|
||||
\subsection{Maven}
|
||||
\subsection{Gradle}
|
||||
\subsection{Собственные прокси, хостинг и закрытая сеть}
|
||||
\subsection{Немного экзотики: Bazel}
|
||||
Система сборки это программа, которая собирает другие программы. На вход система сборки получает исходный код, написанный разработчиком, а на выход выдаёт программу, которую уже можно запустить. Отличается она от компилятора тем, что вызывает его при своей работе, а компилятор о системе сборке и её существовании ничего не знает.
|
||||
|
||||
Так же, все системы сборок имеют схожую верхнеуровневую архитектура, которая сводится к следующему:
|
||||
Если чуть конкретнее, то сборка, помимо компиляции, содержит в себе ещё целый спектр задач, для решения которых компилятор не предусмотрен. Например, первое, что приходит в голову
|
||||
\begin{itemize}
|
||||
\item загрузить зависимые библиотеки для вашего проекта из репозитория, возможно даже из интернета;
|
||||
\item скомпилировать классы модуля или всего проекта как вместе, так и по отдельности;
|
||||
\item сгенерировать дополнительные файлы: SQL-скрипты, XML-конфиги и т.п.;
|
||||
\item удалять/создавать директории и копировать в них указанные файлы;
|
||||
\item упаковка скомпилированных классов проекта в архивы различных форматов: zip, rar, rpm, jar, ear, war и др.;
|
||||
\item компиляция и запуск модульных тестов (unit-test) вашего проекта с результатами выполнения тестов и расчетом процента покрытия;
|
||||
\item развёртывание (deploy) файлов проекта на удаленный сервер;
|
||||
\item генерация документации и отчетов.
|
||||
\end{itemize}
|
||||
|
||||
Конфигурации
|
||||
В конце концов они могут даже вообще код не компилировать, но делать автоматическую рутинную работу: генерация, архивация, операции с файлами, установка на сервер — что позволяет разработчикам эффективнее тратить своё не самое дешёвое для работодателя время.
|
||||
|
||||
Также, стоит упомянуть, что системы сборок имеют схожую верхнеуровневую архитектуру, которая сводится к следующему:
|
||||
\begin{enumerate}
|
||||
\item Конфигурации: собственная и модульная. Там хранятся настройки системы вроде места установки и адресов репозиториев, в модульной же информация о проекте, зависимостях и задачах;
|
||||
\item Парсеры конфигураций как системный для чтения конфигурации системы и её настройки, так и модульный, преобразующий человекочитаемые задачи в исполняемые;
|
||||
\item Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
|
||||
\item Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
|
||||
\item Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
|
||||
\end{enumerate}
|
||||
|
||||
собственная конфигурация, где хранятся «личные» настройки системы. Например, такие как информация о месте установки или окружении, информация о репозиториях и прочее;
|
||||
конфигурация модуля, где описывается место расположения проекта, его зависимости и задачи, которые требуется выполнять для проекта;
|
||||
Для Java систем сборок, по большому счёту, три:
|
||||
\begin{itemize}
|
||||
\item Ant уже можно увидеть только в очень старых проектах, а в чистом видн, наверное, и вовсе не найти. Иногда можно встретить Ant в сочетании с инструментом по управлению зависимостями Ivy;
|
||||
\item Пожалуй, самый популярный инструмент - это Maven, им собирают не только спринг приложения, но и весь энтерпрайз, поэтому я скорее всего не ошибусь, сказав, что он заниимает процентов 70 рынка джава приложений;
|
||||
\item Gradle стремительно завоёвывает рынок, плотно закрепившись в мобильной разработке, андроид студия собирает свои проекты гредлом, да и в остальных проектах люди чаще находят груви и котлин более удобными, чем декларативный хмл;
|
||||
\end{itemize}
|
||||
|
||||
Пожалуй неправильно было бы не упомянуть не совсем стандартную для Java систему сборки Bazel. Её отличает полная кроссплатформенность и кросстехнологичность, что делает её особенно привлекательной для микросервисных проектах, использующих несколько языков программирования. Получается забавно, ант уже почти не используется и сходит на нет, базель возможно наберёт обороты, а инструментов всё равно останется три. О нём мы поговорим в самом конце.
|
||||
|
||||
Парсеры конфигураций
|
||||
\subsection{С чего всё начиналось (Ant, Ivy)}
|
||||
Первым специализированным инструментом автоматизации задач для языка Java появился Ant. По сути, это аналог make-файла, то есть набор скриптов (которые называются тасками, от английского таск - задача, задание). В отличие от make, утилита Ant имеет только одну зависимость — JRE. Ещё одним важным отличием от мейка является отказ от использования команд операционной системы. Всё что пишется в ант пишется на XML, что обеспечивает переносимость сценариев между платформами.
|
||||
|
||||
Управление процессом сборки как только что было сказано, происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (таргетов, с этим понятием мы познакомились когда говорили о мейкфайлах). Цели в терминах ант сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (тасков). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.
|
||||
|
||||
парсер способный «прочитать» конфигурацию самой системы, для её настройки соответствующим образом;
|
||||
парсер конфигурации модуля, где некоторыми «понятными человеку» терминами описываются задачи для системы сборки;
|
||||
|
||||
|
||||
Сама система — некоторая утилита + скрипт для её запуска в вашей ОС, которая после чтения всех конфигураций начнет выполнять тот или иной алгоритм, необходимый для реализации запущенной задачи;
|
||||
Система плагинов — дополнительные подключаемые надстройки для системы, в которых описаны алгоритмы реализации типовых задач;
|
||||
Локальный репозиторий — репозиторий (некоторое структурированное хранилище некоторых данных), расположенный на локальной машине, для кэширования запрашиваемых файлов на удаленных репозиториях.
|
||||
|
||||
|
||||
Какие есть системы сборки
|
||||
(чисто обзор и возможно по два предложения с особенностями)
|
||||
Для Java систем сборок по большому счёту три:
|
||||
|
||||
Ant или Ant в сочетании с инструментов по управлению зависимостями Ivy;
|
||||
Maven;
|
||||
Gradle и Gradle Wrapper;
|
||||
Нестандартная для Java система сборки Bazel.
|
||||
|
||||
|
||||
Ant, Ant+Ivy
|
||||
Первым для автоматизации этих задач появился Ant. Это аналог make-файла, а по сути набор скриптов (которые называются tasks). В отличие от make, утилита Ant полностью независима от платформы, требуется лишь наличие на применяемой системе установленной рабочей среды Java — JRE. Отказ от использования команд операционной системы и формат XML обеспечивают переносимость сценариев.
|
||||
Управление процессом сборки происходит посредством XML-сценария, также называемого Build-файлом. В первую очередь этот файл содержит определение проекта, состоящего из отдельных целей (Targets). Цели сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (Tasks). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.
|
||||
Между целями могут быть определены зависимости — каждая цель выполняется только после того, как выполнены все цели, от которых она зависит (если они уже были выполнены ранее, повторного выполнения не производится). Типичными примерами целей являются clean (удаление промежуточных файлов), compile (компиляция всех классов), deploy (развёртывание приложения на сервере).
|
||||
Скачивание и установка, в случае каких-то неисправностей, ant для Linux выполняется командой вроде sudo apt-get install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив.
|
||||
Проверить версию можно командой ant -version
|
||||
Теперь можно написать простой сценарий HelloWorld
|
||||
|
||||
Скачивание и установка, ant для Linux-подобных ОС выполняется привычной командой установки в вашем пакетном менеджере, вроде sudo apt install ant, а для Windows можно перейти на сайте ant.apache.org и скачать архив, распаковав его и прописав соответствующий путь в переменные среды. Проверить версию можно командой ant -version
|
||||
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=XML,style=ASMStyle]
|
||||
<?xml version="1.0"?>
|
||||
<project name="HelloWorld" default="hello">
|
||||
<target name="hello">
|
||||
<echo>Hello, World!</echo>
|
||||
</target>
|
||||
<target name="hello">
|
||||
<echo>Hello, World!</echo>
|
||||
</target>
|
||||
</project>
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
Теперь можно написать простой сценарий HelloWorld: в нём мы указываем версию хмл, без этого никакой хмл никогда не работает. затем говорим, что наш проект называется приветмир, а собирать по умолчанию для этого проекта надо таргет хелло. далее в проекте идут описания таргетов, в нашем случае таргет будет один, он будет носить имя хелло, а в рамках таргета нужно будет вывести в терминал приветствие миру.
|
||||
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
mkdir hello
|
||||
cd hello
|
||||
ant
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
Затем, нужно создать подкаталог hello и сохранить туда файл с именем build.xml, который содержит сценарий. Далее надо перейти в каталог и вызвать ant. Полный перечень команд:
|
||||
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
$ mkdir hello
|
||||
$ cd hello
|
||||
$ ant
|
||||
Buildfile: /home/hello/build.xml
|
||||
% --- слайд
|
||||
\begin{verbatim}
|
||||
Buildfile: /home/hello/build.xml
|
||||
|
||||
hello:
|
||||
[echo] Hello, World!
|
||||
BUILD SUCCESSFULL
|
||||
\end{lstlisting}
|
||||
\end{verbatim}
|
||||
% --- конец слайда
|
||||
|
||||
В результате выполнения которых получим следующий вывод. Что именно произошло? система сборки нашла файл сценария с именем по умолчанию, по удачному стечению обстоятельств система ищет файл с именем build.хмл и выполнила цель указанную по умолчанию, здесь уже никаких удачных стечений обстоятельств, мы явно указали, что нужно по умолчанию выполнять таргет с именем hello. Чтобы не запутаться в более сложном проекте, мы указали имя проекта, с помощью атрибута name.
|
||||
|
||||
Теперь нужно бы пояснить, что произошло: система сборки нашла файл сценария с указанным по умолчанию именем build и выполнила цель с именем hello, который указан в теге проекта, с помощью атрибута default со значением hello, а также имя проекта, с помощью атрибута name.
|
||||
В стандартной версии ant присутствует более 100 заданий, такие как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete:
|
||||
|
||||
\begin{lstlisting}[language=C,style=CCodeStyle]
|
||||
<!-- Очистка -->
|
||||
<target name="clean" description="Removes all temporary files">
|
||||
% --- слайд
|
||||
\begin{lstlisting}[language=XML,style=ASMStyle]
|
||||
<!-- Очистка -->
|
||||
<target name="clean" description="Removes all temporary files">
|
||||
<!-- Удаление файлов -->
|
||||
<delete dir="${build.classes}"/>
|
||||
</target>
|
||||
</target>
|
||||
\end{lstlisting}
|
||||
% --- конец слайда
|
||||
|
||||
В стандартной поставке ant присутствует более 100 заранее созданных заданий, таких как: удаление файлов и директорий (delete), компиляция java-кода (javac), вывод сообщений в консоль (echo) и т.д. Вот пример реализации удаления временных файлов, используя задание delete
|
||||
|
||||
На данный момент Ant используют в связке с Ivy, которая является гибким, настраиваемым инструментом для управления (записи, отслеживания, разрешения и отчетности) зависимостями Java проекта.
|
||||
|
||||
Некоторые достоинства Ivy:
|
||||
|
||||
гибкость и конфигурируемость – Ivy по существу не зависит от процесса и не привязан к какой-либо методологии или структуре;
|
||||
|
|
@ -153,17 +139,25 @@ Apache Ivy обязана быть сконфигурирована, чтобы
|
|||
Конфигурация модуля определяется в Ivy файле в формате .xml, он будет использоваться, чтобы обнаружить все зависимости для дальнейшей загрузки артефактов. Понятие «загрузка» артефакта имеет различные варианты выполнения, в зависимости от расположения артефакта: артефакт может находиться на веб-сайте или в локальной файловой системе вашего компьютера. В целом, загрузкой считается передача файла из хранилища в кеш Ivy.
|
||||
Пример конфигурации зависимостей с библиотекой Lombok:
|
||||
|
||||
\begin{lstlisting}[language=XML,style=ASMStyle]
|
||||
<ivy-module version="2.0">
|
||||
<info organisation="org.apache" module="hello-ivy"/>
|
||||
<dependencies>
|
||||
<dependency org="org.projectlombok" name="lombok" rev="1.18.24" conf="build->master"/>
|
||||
</dependencies>
|
||||
<info organization="org.apache" module="hello-ivy"/>
|
||||
<dependencies>
|
||||
<dependency org="org.projectlombok" name="lombok" rev="1.18.24" conf="build->master"/>
|
||||
</dependencies>
|
||||
</ivy-module>
|
||||
\end{lstlisting}
|
||||
|
||||
|
||||
Его структура довольно проста, первый корневой элемент <ivy-module version="2.0"> указывает на версию Ivy, с которой данный файл совместим. Следующий тег <info organisation="org.apache" module="hello-ivy"/> содержит информацию о программном модуле, для которого указаны зависимости, здесь определяются название организации разработчика и название модуля, хотя можно написать в данный тег что угодно. Наконец, сегмент <dependencies> позволяет определить зависимости. В данной примере модулю необходимо одна сторонняя библиотека: lombok.
|
||||
Его структура довольно проста, первый корневой элемент <ivy-module version="2.0"> указывает на версию Ivy, с которой данный файл совместим. Следующий тег <info organization="org.apache" module="hello-ivy"/> содержит информацию о программном модуле, для которого указаны зависимости, здесь определяются название организации разработчика и название модуля, хотя можно написать в данный тег что угодно. Наконец, сегмент <dependencies> позволяет определить зависимости. В данной примере модулю необходимо одна сторонняя библиотека: lombok.
|
||||
Однако, у такой системы, как Ant есть и свои минусы: Ant-файлы могут разрастаться до нескольких десятков мегабайт по мере увеличения проекта. На маленьких проектах выглядит всё достаточно неплохо, но на больших они длинные и неструктурированные, а потому сложны для понимания.
|
||||
Что привело к появлению новой системы - Maven.
|
||||
|
||||
\subsection{Репозитории, артефакты, конфигурации}
|
||||
\subsection{Классический подход (Maven)}
|
||||
\subsection{Всем давно надоел XML (Gradle)}
|
||||
\subsection{Собственные прокси, хостинг и закрытая сеть}
|
||||
\subsection{Немного экзотики (Bazel)}
|
||||
|
||||
|
||||
|
||||
\end{document}
|
||||
|
|
@ -576,6 +576,17 @@ CMD java -classpath ./out ru.gb.dj.Main
|
|||
|
||||
Можно даже, например, не брать в качестве исходного образа ждк, а взять ОС, вручную установить на ней ждк и, например, мейк, и автоматизировать всё мейком внутри докера. Это странно, но, как минимум не запрещено.}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{Автоматизация сборки в CLI, контейнеризация}
|
||||
docker run
|
||||
\end{frame}
|
||||
\note{Докерфайл это конечно хорошо, но надо бы его ещё как-то применить, а значит, надо собрать из него образ и запускать потом контейнеры на основе этого образа. Собрать образ не сложно, нужно дать докеру соответствующую команду
|
||||
docker build . -t hellojava:latest
|
||||
где точка, понятно, текущая папка, содержащая докерфайл, а -т это записываемый в образ тег. по этому тегу потом удобнее искать образы. с тегами можно публиковать образы на докерхаб. Готовые образы можно запускать так, чтобы после выполнения контейнер уничтожался, это как раз то, что нам нужно, поскольку в процессе отработки функциональности приложений и создаваемого образа часто приходится создавать контейнеры после изменения каждой строки, а это очень много контейнеров, поэтому добавим флаг --рм и получим строку
|
||||
docker run --rm hellojava:latest
|
||||
запустив которую получим в терминале долгожданный хеловорлд
|
||||
}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{итоги}
|
||||
что изучили и домашка
|
||||
|
|
|
|||
Loading…
Reference in New Issue