Отличное средство сборки Java-приложений

В прошлом номере "Компьютерных вестей" мы с вами говорили о таком инструменте, как Automated Build Studio - универсальной системе сборки проектов для самых разных языков программирования. Сегодня я решил остановиться подробнее на сборке проектов для Java, поскольку именно этот язык программирования чаще всего используют белорусские программисты.

ANT versus остальные

Java-приложения, как известно, отличаются своей кросс-платформенностью. Значит, и инструмент сборки для них нужен самый что ни на есть кросс-платформенный. Стандартный инструмент сборки GNU make, портированный на множество платформ, конечно, кросс-платформенностью обладает, однако в его идеологии эта кросс-платформенность и близко не присутствует. Почему? Достаточно посмотреть на скрипты, которые управляют сборкой проектов. Вы без труда убедитесь, что в их основе лежит UNIX'овый shell script, с которым совершенно не обязательно хорошо знакомы программисты, использующие ту же Windows. Да и для Java-программиста изучение UNIX'ового shell script'а - занятие явно не приоритетное.

Что касается недавно рассмотренного мною на страницах "Компьютерных вестей" хорошего, удобного, визуального и т.д., и т.п. инструмента под названием Automated Build Studio, то с ним, к сожалению, всё едва ли не ещё более печально, поскольку он и вовсе умеет работать исключительно и только под Windows. Да и заточен, судя по набору поддерживаемых функций, совсем не под Java, а под Delphi или Visual C++. То есть, тоже далеко не лучший выбор, как и многие другие аналогичные Automated Build Studio по функциональности инструменты.

Так что ANT, написанный на Java и использующий для записи build-скориптов не какой-нибудь платформенный скрипт, а внутренний язык, основанный на XML-нотации, выглядит намного более привлекательно, чем упомянутые выше два варианта сборщиков.

Тем не менее, наверняка найдутся и скептики, которые заявят, что есть и более продвинутый инструмент сборки, Maven, разработанный, кстати, всё тем же Apache Foundation. Что ж, против Maven я и сам возражать не буду. Просто, как мне кажется, ANT, разрабатываемый дольше, несёт в своих внутренностях меньше всяческих багов, характерных для open-source'ных программных продуктов, так что использовать его всё же предпочтительнее, чем более молодой Maven.

Общие сведения и установка

Для начала скажу, что, поскольку меня уже не раз упрекали в неконкретности статей, то эту я постараюсь сделать максимально конкретной и практичной - насколько это вообще возможно для газетной статьи. Ну а получится или нет, судить уже вам.

Найти ANT во Всемирной сети можно по адресу ant.apache.org. Поскольку ANT - это Java-приложение, то вас не будут спрашивать, для какой операционной системы вам нужен дистрибутив ANT'а. Если нужен дистрибутив, скачивайте кросс-платформенный дистрибутив, если нужны исходные тексты - скачивайте не менее кросс-платформенные исходники. Всё просто, как видите.

Установка ANT'а заключается в распаковке архива с дистрибутивом и прописывании некоторых системных переменных для его корректной работы. Под Windows (за другие ОС не поручусь) в переменную PATH нужно добавить путь к bin-подкаталогу той директории, в которой установлен ANT, а саму эту директорию записать в переменную ANT_HOME. Также нужно прописать специальную системную переменную JAVA_PATH, в которой указать ANT'у путь к той директории, в которую установлен JDK.

XML-скрипты ANT'а

Как я уже говорил выше, для записи скриптов в ANT'е используется специальное собственное подмножество универсального языка разметки XML. Файл, который будет содержать в себе инструкции по сборке, должен иметь название build.xml и размещаться в корневой директории проекта. Конечно, вполне возможно использовать и отличное от этого название build-файла, но тогда его нужно будет указывать ANT'у в качестве параметра командной строки.

Давайте я сначала дам пример build-скрипта для ANT'а, а потом уже расскажу, что в нём для чего нужно.

<project name="HelloWorld" basedir="." default="main">
<property name="src.dir" value="."/>
<property name="build.dir" value="build"/>
<property name="classes.dir" value="build/classes"/>
<property name="jar.dir" value="build/jar"/>
<property name="main-class.client" value="RemoteClient"/>
<target name="clean">
 <delete dir="$(build.dir)"/>
</target>
<target name="init">
 <mkdir dir="${build.dir}"/>
 <mkdir dir="${classes.dir}"/>
 <mkdir dir="${jar.dir}"/>
</target>
<target name="compile" depends="init">
 <javac srcdir="." destdir="${classes.dir}"
  classpath="${classpath};H:\Projects\;./log4j.jar"/>
 <rmic base="${classes.dir}" classname="RemoteServer"/>
</target>
<target name="jar" depends="compile">
 <jar destfile="${jar.dir}/Client.jar"
  basedir="${classes.dir}">
 <manifest>
  <attribute name="Main-Class"
   value="${main-class.client}"/>
 </manifest>
 </jar>
</target>
<target name="run" depends=" jar ">
 <java jar="${jar.dir }/Client.jar" fork="true"
  classpath="${classpath};d:\Projects\;./log4j.jar">
 </java>
</target>
<target name="main" depends="clean,run"/>
</project>

Первое, что становится заметно, это то, что в XML-файле ANT'а нет привычной строки вида "<?xml version="1.0" encoding="UTF-8"?>". В этом заключается особенность ANT'овских XML-файлов, однако какого-то особого глубокого смысла в ней, как мне кажется, искать не стоит.

Корневой элемент всего документа - это project. Здесь указаны имя проекта, корневая директория (в приведённом примере такой является текущая директория) и вызываемый по умолчанию сборщиком target. О том, что такое этот самый target, будет буквально абзацем или двумя ниже.

Дальше идут вложенные элементы, первые несколько из которых - это элементы типа property. В общем-то, если быть кратким, то в ANT'е так называются именованные константы, которые затем (это видно и далее по самому тексту build-файла) используются вместо фактических значений путей к директориям, имён классов и прочих подобных вещей. Все property должны быть записаны вне target'ов.

Вот теперь, собственно, о самих target'ах. Таким хитрым образом в ANT'е названы отдельные задачи, на которые, удобства ради, разбивается весь процесс сборки проекта. В приведённом примере это следующие задачи: clean (удаление всего скомпилированного в прошлый раз), init (создание поддиректорий для class и jar-файлов), compile (компиляция исходного текста проекта в class-файлы), jar (сборка исполняемых jar-файлов) и run (запуск jar'ов на выполнение с помощью виртуальной машины Java). Как не сложно заметить, все target-элементы являются по своей природе составными и содержат внутри себя, собственно, действия, необходимые для успешного выполнения той или иной операции в рамках сборки проекта. При этом, поскольку выполнение каждого последующего target'а невозможно без выполнения всех предыдущих (кто ж сможет запустить программу на выполнение, если её даже не удалось скомпилировать?), то target'ы, указанные как зависимые от каких-то других target'ов с помощью установки атрибута depends, будут запускаться только при условии выполнения всех target'ов, которые указаны в этом атрибуте.

Операции внутри target'ов тоже обозначены XML-тегами. Догадаться об их значении, в общем-то, особой сложности не составляет, но я всё же, на всякий случай, поясню. Команда delete нужна для удаления файлов и директорий, javac - для компиляции исходных текстов классов в байт-код (то есть, в class-файлы); mkdir занимается тем, что создаёт директории, jar собирает исполняемые файлы для виртуальной машины Java из class-файлов. Их потом запускаем с помощью команды java. Есть и другие широко используемые при написании build-скриптов в ANT'е команды, которые в данном примере нам с вами не встретились. К ним относятся copy, которая, конечно же, как и следовало ожидать, копирует файлы из одной директории в другую; move, которая файлы перемещает; exec, которая запускает какие-нибудь внешние программы или команды операционной системы; cvs, выполняющая извлечение кода из системы контроля версий CVS, или junit, выполняющая тестирование кода с использованием мощного фреймворка JUnit, нужного, конечно, как видно из его названия, для unit-тестирования.

Конечно, на этом логика XML-файлов ANT'а не исчерпывается, но её самую существенную часть мы с вами вполне успешно разобрали, так что дальше, я думаю, для вас не составит труда разобраться самостоятельно с помощью документации, которую можно найти на официальном сайте этого программного продукта.

Подведём итоги

Конечно, кто-то может сказать, что ANT менее удобен, чем make, но я с этим человеком позволю себе не согласиться. Привычка, конечно, вторая натура, но нельзя весь мир мерить собственными привычками. Каждый человек имеет право на привычку использовать именно тот инструмент, который ему удобнее. Что касается сравнения с Automated Build Studio (оно как-то само собой напрашивается, раз уж в прошлом номере я рассказывал об аналогичном, в общем-то, ANT'у инструменте), то и здесь всё не так просто. С одной стороны, конечно, такого удобства визуального конструирования и отладки сценариев, как в Automated Build Studio, ANT'у пока (да и в будущем вряд ли, если честно) достичь не удалось. Но, тем не менее, для Java-программиста ANT удобнее, так как заточен именно под этот язык программирования. Так что ANT, на самом-то деле, очень полезный и нужный инструмент.

Вадим СТАНКЕВИЧ,
dreamdrusch@tut.by