Gradle: нам нужен еще один инструмент для сборки?

На ранних этапах разработки Java мы либо не видели особой необходимости в инструментах сборки, либо использовали то, что у нас было в других средах. Я до сих пор помню, как создавал сценарии оболочки и создавал файлы для разработки Java. Файлы make были особенно интересны, потому что это был инструмент, который не был разработан с учетом Java. Также было сложно перейти на другие операционные системы.

Там, где я работал в те дни, мы разрабатывали Solaris, но у нас было несколько проектов, которые существовали как для Windows, так и для Solaris — это было одной из причин, по которой мы нашли и начали использовать «новый» язык, по крайней мере, новый тогда. Это делало невозможным использование сценариев оболочки, а в лучшем случае затрудняло работу с файлами.

Когда муравей вышел, мы прыгнули на него. Как и язык, на котором мы работали, он был кроссплатформенным. Это было огромным преимуществом для нас.

Я помню, когда появился Maven, было некоторое сопротивление, потому что у нас был Ant. Но к этому времени некоторые проекты стали достаточно большими и достаточно сложными, так что было сложно писать и поддерживать файлы Ant. С появлением файлов war и загрузкой jar-файлов зависимостей из classpath также стало отвлекать поиск, загрузку и установку всех jar-зависимостей для каждого проекта. Обещание Maven по управлению зависимостями и упрощение сборки по соглашению сделали этот инструмент обязательным в нескольких проектах. Многие магазины, в которых я работал на протяжении многих лет, использовали возможности, которые Maven привносит в среду программирования.

Возникает вопрос: нужен ли нам такой мощный инструмент?

В качестве иллюстрации я вернусь к тем дням, когда я стал программистом и работал на строительстве. Так как я был сыном владельца компании, я «получил» работать во всех сферах строительного процесса. Я нашел, что мне действительно понравился обрамляющий молоток. У него был хороший ход, и я мог легко с ним вбить 16 грошей. Так что я использовал это везде; Я использовал его для обрамления, раскроя шпунта, отделочных работ, кровли, но не столько для электромонтажных работ.

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

О Gradle

Недавно я смотрел на инструмент сборки Gradle . Одна вещь, которая сразу бросается в глаза, это то, что файл сборки не является XML, файлом свойств или любым другим текстовым файлом только для конфигурации. Это Groovy скрипт. Из первой части этой статьи, я думаю, вы можете сказать, что я довольно давно программист на Java. До этого это были C и C ++. Языки на основе C, особенно Java, для меня вторая натура. XML — это то, что выводит мой код или используется для обеспечения конфигурации сервера или другого инструмента. Я не работаю со структурой этого почти так же, как я работаю на Java, который весь день. С Groovy я чувствую себя как дома, так как он основан на Java.

Эта статья предназначена не для того, чтобы перейти с Maven на Gradle, а для того, чтобы узнать, почему Gradle должен быть в вашем поясе инструментов. У Стива Эберсоле есть отличная статья о том, почему Hibernate перешел из Maven в Gradle для своих сборок. На мой взгляд, Maven по-прежнему отличный инструмент, когда у вас есть проект, который может или должен использовать соглашения Maven.

Это также не является руководством по использованию Gradle. Уже есть несколько хороших мест для начала, включая руководство пользователя на веб-сайте Gradle .

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

Пример в действии

Самая мощная особенность Gradle для меня — тот факт, что скрипты являются кодом. Groovy, чтобы быть точным. Иногда все мы сталкиваемся с проектами, у которых есть одно требование, которое отличает их от других проектов. Пару раз я писал быстрые проекты Griffon для поддержки данных конфигурации, для которых в противном случае мне пришлось бы поддерживать сценарии SQL. Griffon — это среда приложений быстрого рабочего стола Groovy, которая создает автономные приложения, которые могут быть развернуты в виде исполняемых файлов JAR или апплетов. Когда мне нужно будет внести изменения, мне нужно будет скопировать его в каталог, из которого я запускал приложение, или в сеть, чтобы кто-то другой мог его запустить.

Gradle позволяет мне написать этот сценарий построения логики. Поскольку Gradle основан на Groovy, он поставляется со всеми инструментами и библиотеками Groovy и Java. Например, добавить диалоговое окно Swing, чтобы выбрать каталог, в который следует скопировать JAR, и затем выполнить копирование так же просто, как добавить код в файл сборки:

Затем запустите copyJar из вашей IDE или командной строки, задайте задачу выбора каталога и скопируйте файл.

Ладно, это может быть немного надуманным, но рассмотрим аналогичное требование для FTP файла на сервер или с сервера во время сборки. Вы можете использовать что-то вроде SimpleFTP из Jibble, чтобы обеспечить это требование. Поскольку он поставляется в виде файла JAR, который вы можете поместить в путь к классу, вы можете просто использовать его в своем скрипте сборки так же, как я использую здесь JFileChooser.

В заключение, Gradle — это мощный и универсальный инструмент, который заслуживает места в вашем поясе инструментов.