Читатели моего блога знают, что я фанат Maven . Я начал использовать Maven около 2007-8 и никогда не оглядывался назад. Однако, как и во всем остальном, «изменение — единственная константа». Сейчас в этой области есть и другие игроки, и Gradle выглядит наиболее перспективным из всех. Я решил дать ему шанс, и я поделился суть своих выводов / обучения в этой статье (конечно, одна статья едва ли поцарапать поверхность, но это все-таки начало). Если вы работаете над проектами на основе Java и используете Maven, вы можете найти эту статью интересной для чтения.
Что такое Gradle?
Gradle представляет себя как средство автоматизации предприятия. Исходя из того, что я видел до сих пор, я склонен согласиться с тем, что, похоже, все галочки отмечены рамками для такой цели. Тем не менее, это немного BHAG, продажный разговор. Это хорошая цель (например, попытка стать инструментом автоматизации предприятия), но лично я думаю, что это амбиция, а не реальность на данный момент.
Снятие амбиций и продвижение продаж — с точки зрения технократа Java — Gradle (похоже) быстро становится хорошим инструментом для обработки всех действий, связанных со сборкой и выпуском для Java-проектов.
Почему я должен беспокоиться сейчас? Maven прекрасно работает для меня.
Да, это так. Я работаю с некоторыми довольно крупными предприятиями, и, честно говоря, даже если они получат все свои Java-проекты на Maven, они бы сделали большой шаг вперед. Таким образом, для всех практических целей — по моему опыту — в обычном корпоративном предприятии — Maven не только достаточно хорош, но и делает большой шаг вперед, если его правильно и широко использовать.
Сказав, что, хотя у предприятий есть роскошь (и в действительности необходимость) защищаться с помощью инструментов и технологий, мы, технократы, не роскошь. Когда инструмент / технология / инфраструктура доказывают, что он эффективен, предприятия могут нанять консультантов, которые знают эти инструменты (и иногда умные слова), и тех технократов, которые не потратили достаточно усилий, чтобы постоянно обновляться, могут оказаться в курсе всех проблем. Хитрость заключается в том, чтобы знать, на какую технологию тратить время, а на какую нет.
Что касается Gradle, то ему удалось получить несколько действительно впечатляющих покровителей. Весенние люди переместили ядро Весны в Gradle. Hibernate люди подробно документировали причины их перехода на Gradle. Кажется, у людей из Grails есть твердое мнение в пользу Gradle.
Я не собираюсь пытаться заручиться добротой Gradle. Во-первых, я еще недостаточно знаю об инструменте. Во-вторых, ссылки, которыми я уже поделился, принадлежат некоторым довольно громким именам, работающим с довольно успешными технологическими компаниями, и они проделали довольно хорошую работу по объединению преимуществ Gradle.
Мое простое резюме будет
- Gradle позволяет вам кодировать вещи в Groovy. Следовательно, вы можете в значительной степени кодировать все, что вы хотите, чтобы ваш скрипт сборки и выпуска делал.
- Gradle — имея возможность учиться у своих предшественников, таких как Maven — похоже, исправил несколько проблем в самом начале. Работа с несколькими модулями, работа с несколькими исходными папками и т. Д. Будут хорошими примерами.
- Не быть рядом, пока Maven означает, что поддержка немного отрывочна.
Плагин для STS, который я использовал, определенно имел некоторые неровные края. - Поскольку вы можете кодировать практически все, что захотите, так же легко выстрелить себе в ногу. Быть таким гибким — я думаю, что для предприятий будет непросто иметь стандартизированную сборку и выпуск для разных проектов с использованием Gradle.
Итак, поехали. Два очка за и два очка против. Довольно сбалансированный. Этого было достаточно, чтобы заинтересовать меня. Если вы тоже заинтригованы, молитесь, читайте дальше.
ОК. Итак, как мне начать?
Я бы порекомендовал вам начать с закладки нескольких ссылок. Gradle домашняя страница , страница загрузки , список связанных инструментов . Сборка и тестирование с Gradle , электронная книга. Это полностью стоит регистрации. Я рекомендую это. Наконец, руководство пользователя Gradle , которое вы сможете лучше понять после того, как потратите больше времени на Gradle.
Итак, загрузите последнюю версию. У меня есть версия 1.3 для этой статьи. Разархивируйте его и поместите в любое удобное для вас место. Я обычно выкидываю такие инструменты (основанные на Java) в C: \ ProgramFiles (обратите внимание на отсутствие места между Program -? — Files). Поэтому для этой статьи у меня есть папка C: \ ProgramFiles \ gradle-1.3 со всеми вкусностями Gradle, которые мы только что скачали.
Нам нужно немного подправить файл gradle.bat. Добавьте JAVA_HOME в начале командного файла. Gradle должен иметь доступ к Java-установке машины. Оставьте остальную часть файла как есть.
Файл: C: \ ProgramFiles \ gradle-1.3 \ bin \ gradle.bat
|
1
2
3
4
|
SET JAVA_HOME=C:\ProgramFiles\Java\jdk1.7.0_09...@if '%DEBUG%' == '' @echo off ...... |
Теперь, просто чтобы проверить, что все правильно соединено, создайте командный файл. Это всего лишь одна строка, поэтому вы могли просто ввести ее в командной строке. Но я склонен помещать это в пакетный файл, так как я добавляю еще кое-что позже.
Файл: C: \ ProgramFiles \ gradle-1.3 \ bin \ GradleCommands.bat
|
1
|
gradle -v |
Если вы запустите этот командный файл, вы увидите, что Gradle объявит его версию. Если вы до сих пор со мной, у вас есть ванильный Gradle, работающий на вашей машине. Поздравляю. Однако этого не будет достаточно для большинства ваших практических целей. Давайте сложим немного больше на инструментах .
Я больше не использую Затмение. STS действительно проделал очень хорошую работу, и я использую ее уже пару лет. К счастью, есть и плагин Gradle для STS . Процедура установки хорошо документирована, и я не буду повторять ее здесь. Однако процедура установки не говорит о том, что она не так проста. Я попробовал это на двух разных машинах, и мне пришлось пройти через несколько обручей, прежде чем я смог заставить его работать. Мой совет будет не пробовать это с вашей рабочей установкой Eclipse / STS, если вы не можете позволить себе сломать его на пару часов. Сделайте еще один экземпляр STS и отработайте его. Ваша настойчивость будет вознаграждена новой функцией импорта Gradle (и некоторыми другими , которые мы проверим позже) в STS.
И последнее: прежде чем идти дальше, откройте «настройки» в STS и установите Gradle в папку C: \ ProgramFiles \ gradle-1.3. Мне нравится следить за тем, чтобы STS просто управлял ванильным Gradle и ничего больше. При необходимости я могу выйти из STS и ввести те же команды в командной строке и быть уверенным в том же результате. Я люблю делать вещи из редактора, но презираю, что их заблокировали. Как только это будет сделано, вам понадобится проект на основе Java (использующий Gradle) для импорта.
Как создать проект Java на основе Gradle для импорта в STS?
Здесь начинается веселье. Просто создайте папку (я назову ее gradle001). Поместите в него файл build.gradle. Это все, что нужно STS для импорта. В том, что входит в build.gradle, есть немного теории. Я не буду вникать в это прямо сейчас. Давайте просто посмотрим на следующий файл build.gradle.
Файл: /gradle001/build.gradle
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
|
apply plugin: 'java'def localMavenRepo = 'file://D:/mavenrepo'repositories { mavenCentral() maven { url= localMavenRepo }}sourceCompatibility = 1.7version = '1.0-SNAPSHOT'group = 'foo.bar.gradle'dependencies { testCompile 'junit:junit:4.11'} |
Вы видите интересную часть сейчас? Хотя я не добавил ни одной строки комментария в файл, вы можете догадаться, что там значат большинство инструкций? Надеюсь, большинство из вас Как вы знаете, я использовал Maven, и локальный репозиторий был сохранен в D: / mavenrepo. Используя Gradle, я мог бы просто использовать этот локальный репозиторий, а также использовать центральный репозиторий maven. С моей точки зрения, Грэдл не мог быть более дружелюбным с Мейвеном, и я люблю Грэдла за то, что он сделал усилия, чтобы сделать жизнь разработчиков намного проще.
Теперь мы запустим STS (с Gradle) и импортируем «новый проект Gradle», где мы импортируем только что созданную структуру папок. Если все было в порядке, вы увидите, что проект прекрасно смотрится в STS. Мой личный опыт был немного отрывочен в этом. Я должен был попробовать это пару раз, прежде чем заставить его работать. Но как только импорт был успешным, все стало намного проще.
Но этот проект не имеет ничего. Maven обычно давал мне более полный проект с фиктивным основным классом и тестовым классом.
Да. Maven использовал для «создания» проекта для вас, и вы могли выбрать любой из множества шаблонов (архетипов) для создания структуры вашего проекта. Увы, я не смог найти аналогичную функциональность с Gradle (как я признал в начале этой статьи, я новичок в этом инструменте и, следовательно, если я что-то упустил, пожалуйста, дайте мне знать. Оставьте комментарий, пожалуйста).
Это факт, что для вас не создан фиктивный проект. Однако сила инструмента, т.е. Gradle, не в этом. Мы уже видели, как легко было читать build.gradle. Теперь давайте напишем некоторый фиктивный код и посмотрим сами, что может сделать для нас Gradle.
Файл: /gradle001/src/main/java/foo/bar/AppMain.java
|
01
02
03
04
05
06
07
08
09
10
|
package foo.bar;public class AppMain { public static void main(String[] args) { System.out.println(new AppMain().greet()); } public String greet() { return 'Hello world.'; }} |
Файл: /gradle001/src/test/java/foo/bar/AppMainTest.java
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
package foo.bar;import static org.junit.Assert.*;import org.junit.Test;public class AppMainTest { @Test public void test() { assertEquals(new AppMain().greet(), 'Hello world.'); }} |
Обновленный файл: /gradle001/build.gradle
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
|
apply plugin: 'java'def localMavenRepo = 'file://D:/mavenrepo'repositories { mavenCentral() maven { url= localMavenRepo }}sourceCompatibility = 1.7version = '1.0-SNAPSHOT'group = 'foo.bar.gradle'dependencies { testCompile 'junit:junit:4.11' }task(runSimple, dependsOn: 'build', type: JavaExec) { main = 'foo.bar.AppMain' classpath = sourceSets.main.runtimeClasspath} |
Это все. Теперь, если мы запустим задачу runSimple в build.gradle, Gradle сделает для нас очень много вещей. Он будет выполнять стандартную очистку, компиляцию, тестирование, создание отчета о тестировании (посмотрите /gradle001/build/reports/tests/index.html на вашем компьютере, если вы до сих пор кодировали этот материал. приятно удивлен), построить и наконец запустить основной класс. Все это около 18 строк build.gradle. Должен сказать, я не думаю, что это плохая сделка.
О, но это 18 строк кода, чтобы построить около 25 строк кода. Подумаешь?
Вы правы. Но вы упускаете суть. Даже если бы это было 25 000 строк кода, эти 18 строк сценария сборки работали бы очень хорошо. Если вы все еще не уверены, я рекомендую вам прочитать эту статью, где сценарий сборки из 264 строк, кажется, работает феноменально хорошо.
Хм… хорошо, но Maven «возможно» тоже не был намного длиннее?
Возможно, ты прав. Хотя люди, кажется, предоставляют всевозможные аргументы и данные против этой возможности, но я не думаю, что это актуальный вопрос для обсуждения.
Дело в том, что pom.xml в Maven — это просто файл конфигурации. В обычный день обычный человек, занимающийся сборкой и выпуском, ничего не кодирует в Maven. Конечно, Maven позволяет создавать всевозможные плагины, и они решают «большую часть» проблемы. Но, похоже, именно это («большинство») является предметом спора. В тех случаях, когда сценарий / требование выходит за рамки «большинства» сценариев, с Maven очень сложно работать. И поскольку технологическая экосистема становится все более разнообразной, люди восстают против этой оковы.
Лично я думаю, что так идет история. Пакетные файлы (xyz.bat) были невероятно мощными, но управлять ими было трудно (читать невозможно). Вы должны были написать их по-разному для разных ОС. Там не было никакой иерархии задач. Я не знаю никого, кто хотел бы поддерживать их для любого, кроме самых тривиальных проектов.
Отсюда и пришел муравей. Он также был невероятно мощным и хорошо справлялся с управлением задачами. У вас были цели почти для всего, а для тех, кого у вас не было, вы можете просто написать код в командном файле и вызвать его из Ant. Там, где это не удалось, была стандартизация. Люди использовали его всевозможными способами в своих проектах, и в большинстве проектов сценарии сборки сами стали проектом. Управлять ими было сложно, только пара человек в команде точно знала, как они работают, и никто не хотел их изменять.
Это где Maven забил большое время. Он соответствовал «большинству» требований, таких как очарование, последовательным образом. Был установлен способ сделать большинство вещей. Таким образом, сценарии сборки больше не были черной дырой. А средний Джо с меньшей вероятностью выстрелил себе в ногу со сценариями Maven.
С Gradle мы заигрываем с большей силой. Ожидается, что средний разработчик будет кодировать с Gradle, а не только настраивать плагины (как в Maven). Таким образом, среднестатистическому разработчику будет легче выполнять работу, когда он / она чувствует себя хорошо.
И именно тогда проект рискнул бы создать сценарий сборки, который потенциально мог бы нанести серьезный ущерб, не имея при этом никакой базы знаний, разработчики будут любить программировать в нем, но ненавидят поддерживать его, у менеджеров будут кошмары о сценарии сборки провалиться за день до демо и придется с этим смириться.
Это звучит не очень обнадеживающе. Что именно вы говорите тогда?
Из того, что я видел в Maven — и, похоже, люди со мной согласны, предпочитают они Gradle или нет — он хорошо выполняет стандартные / средние / большинство требований. Он делает то, что делает очень хорошо. И есть границы, которые не позволяют вам прорваться, где это можно рассматривать как как окову, так и как средство безопасности. Если вы создаете другое веб-приложение J2EE / настольное Java-приложение со стандартным технологическим стеком, я бы сказал, что нет причин отказываться от Maven. Если вы еще не приняли это, пожалуйста, сделайте так, что ваша жизнь станет намного легче.
Однако, если вы участвуете в проекте по разработке продукта и вы раздвигаете границы того, что java / j2ee было воспринято как способное (и при условии, что вы не нанимали только среднестатистического Джо), я думаю, вы можете попробовать Gradle , Это действительно способно. С ним весело работать. Я думаю, что путь для Gradle действительно яркий и полон возможностей. Это хорошая вещь, чтобы тратить время.
Это все на сегодня.
Если вы читали до сих пор, надеюсь, вам это понравилось или, по крайней мере, оно показалось вам интересным. Моя статья основана исключительно на том, что я возился с Gradle, и это не последнее слово в этой теме, какое-то воображение. Если вы найдете что-то не так — или правильно в этой статье, пожалуйста, оставьте комментарий ниже. Я буду очень благодарен.
Ссылка: Gradle — перспектива Maven от нашего партнера JCG Partho в блоге Tech for Enterprise .