Maven gradle ant что это

Maven

Maven — это инструмент для сборки Java проекта: скачивание дополнительных библиотек, компиляции, создания jar, генерации документации. Простые проекты можно собрать в командной строке. Если собирать большие проекты из командной строки, то команда для сборки будет очень длинной, поэтому её иногда записывают в bat/sh скрипт. Но такие скрипты зависят от платформы. Для того чтобы избавиться от этой зависимости и упростить написание скрипта используют инструменты для сборки проекта. Для платформы Java существуют два основных инструмента для сборки: Ant и Maven. Gradle — система автоматической сборки, построенная на принципах Ant и Maven.

Презентацию с видео можно скачать на Patreon .

1. Преимущества и недостатки Maven
2. Установка Maven
3. Maven — жизненный цикл сборки
4. Файл pom.xml
5. Репозитории
6. Плагины Maven
7. Задания

Trustpilot
Комментарии

Зарегистрируйтесь или войдите, чтобы иметь возможность оставить комментарий.

Муравей против Maven против Gradle

В этой статье мы рассмотрим три инструмента автоматизации сборки Java, которые доминировали в экосистеме JVM — Ant, Maven и Gradle .

Мы представим каждый из них и рассмотрим, как развивались средства автоматизации сборки Java.

2. Апачский муравей​

Вначале Make был единственным доступным инструментом автоматизации сборки, помимо собственных решений . Make существует с 1976 года, и поэтому он использовался для создания Java-приложений в первые годы существования Java.

Однако многие соглашения программ на C не подходили для экосистемы Java, поэтому со временем Ant стал лучшей альтернативой.

Apache Ant («Еще один аккуратный инструмент») — это библиотека Java, используемая для автоматизации процессов сборки Java-приложений . Кроме того, Ant можно использовать для создания приложений, отличных от Java. Первоначально он был частью кодовой базы Apache Tomcat и был выпущен как отдельный проект в 2000 году.

Во многих аспектах Ant очень похож на Make, и он достаточно прост, поэтому любой может начать использовать его без каких-либо особых предварительных условий. Файлы сборки Ant записываются в формате XML и по соглашению называются build.xml .

Различные этапы процесса сборки называются «целями».

Вот пример файла build.xml для простого проекта Java с основным классом HelloWorld :

 project>   target name="clean">   delete dir="classes" />   target>    target name="compile" depends="clean">   mkdir dir="classes" />   javac srcdir="src" destdir="classes" />   target>    target name="jar" depends="compile">   mkdir dir="jar" />   jar destfile="jar/HelloWorld.jar" basedir="classes">   manifest>   attribute name="Main-Class"   value="antExample.HelloWorld" />   manifest>   jar>   target>    target name="run" depends="jar">   java jar="jar/HelloWorld.jar" fork="true" />   target>   project> 

Этот файл сборки определяет четыре цели: clean , compile , jar и run . Например, мы можем скомпилировать код, запустив:

 ant compile 

Это сначала вызовет целевую очистку , которая удалит каталог «classes». После этого целевой компилятор воссоздаст каталог и скомпилирует в него папку src.

Основным преимуществом Ant является его гибкость. Ant не навязывает никаких соглашений о написании кода или структуры проекта. Следовательно, это означает, что Ant требует, чтобы разработчики сами писали все команды, что иногда приводит к огромным файлам построения XML, которые трудно поддерживать.

Поскольку никаких соглашений нет, простое знание Ant не означает, что мы быстро поймем любой файл сборки Ant. Скорее всего, потребуется некоторое время, чтобы привыкнуть к незнакомому файлу Ant, что является недостатком по сравнению с другими, более новыми инструментами.

Сначала в Ant не было встроенной поддержки управления зависимостями. Однако, поскольку в последующие годы управление зависимостями стало обязательным, Apache Ivy был разработан как подпроект проекта Apache Ant. Он интегрирован с Apache Ant и следует тем же принципам проектирования.

Однако первоначальные ограничения Ant из-за отсутствия встроенной поддержки управления зависимостями и разочарований при работе с неуправляемыми файлами сборки XML привели к созданию Maven.

3. Апач Мавен​

Apache Maven — это средство управления зависимостями и автоматизации сборки, в основном используемое для приложений Java. Maven продолжает использовать XML-файлы так же, как и Ant, но гораздо более управляемым способом. Название игры здесь — соглашение о конфигурации.

В то время как Ant обеспечивает гибкость и требует, чтобы все было написано с нуля, Maven полагается на соглашения и предоставляет предопределенные команды (цели).

Проще говоря, Maven позволяет нам сосредоточиться на том, что должна делать наша сборка, и дает нам основу для этого. Еще одним положительным аспектом Maven была встроенная поддержка управления зависимостями.

Файл конфигурации Maven, содержащий инструкции по сборке и управлению зависимостями, по соглашению называется pom.xml . Кроме того, Maven также предписывает строгую структуру проекта, в то время как Ant также обеспечивает гибкость.

Вот пример файла pom.xml для того же простого проекта Java с основным классом HelloWorld , что и раньше:

 project xmlns="http://maven.apache.org/POM/4.0.0"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0   http://maven.apache.org/xsd/maven-4.0.0.xsd">   modelVersion>4.0.0modelVersion>   groupId>foreachgroupId>   artifactId>mavenExampleartifactId>   version>0.0.1-SNAPSHOTversion>   description>Maven exampledescription>    dependencies>   dependency>   groupId>junitgroupId>   artifactId>junitartifactId>   version>4.12version>   scope>testscope>   dependency>   dependencies>   project> 

Однако теперь структура проекта также стандартизирована и соответствует соглашениям Maven:

 +---src | +---main | | +---java | | | \---com | | | \---foreach | | | \---maven | | | HelloWorld.java | | |  | | \---resources | \---test | +---java | \---resources 

В отличие от Ant, нет необходимости определять каждую фазу процесса сборки вручную. Вместо этого мы можем просто вызывать встроенные команды Maven.

Например, мы можем скомпилировать код, запустив:

 mvn compile 

По своей сути, как отмечается на официальных страницах, Maven можно считать фреймворком для выполнения плагинов, поскольку вся работа выполняется плагинами. Maven поддерживает широкий спектр доступных плагинов , и каждый из них можно дополнительно настроить.

Одним из доступных плагинов является Apache Maven Dependency Plugin, который имеет цель копирования зависимостей , которая копирует наши зависимости в указанный каталог.

Чтобы показать этот плагин в действии, давайте включим этот плагин в наш файл pom.xml и настроим выходной каталог для наших зависимостей:

 build>   plugins>   plugin>   groupId>org.apache.maven.pluginsgroupId>   artifactId>maven-dependency-pluginartifactId>   executions>   execution>   id>copy-dependenciesid>   phase>packagephase>   goals>   goal>copy-dependenciesgoal>   goals>   configuration>   outputDirectory>target/dependencies  outputDirectory>   configuration>   execution>   executions>   plugin>   plugins>   build> 

Этот плагин будет выполняться на этапе пакета , поэтому, если мы запустим:

 mvn package 

Мы запустим этот плагин и скопируем зависимости в папку target/dependencies.

Существует также существующая статья о том, как создать исполняемый файл JAR с помощью различных подключаемых модулей Maven. Кроме того, для подробного обзора Maven ознакомьтесь с основным руководством по Maven , в котором рассматриваются некоторые ключевые функции Maven.

Maven стал очень популярным, так как файлы сборки теперь были стандартизированы, и для поддержки файлов сборки требовалось значительно меньше времени по сравнению с Ant. Однако, хотя файлы конфигурации Maven более стандартизированы, чем файлы Ant, они все же имеют тенденцию становиться большими и громоздкими.

За строгие соглашения Maven приходится платить гораздо меньшей гибкостью, чем в Ant. Настройка цели очень сложна, поэтому писать собственные сценарии сборки намного сложнее, чем в Ant.

Несмотря на то, что в Maven были внесены некоторые серьезные улучшения, касающиеся упрощения и стандартизации процессов сборки приложений, он по-прежнему имеет свою цену из-за гораздо меньшей гибкости, чем Ant. Это привело к созданию Gradle, который сочетает в себе лучшее из обоих миров — гибкость Ant и функции Maven.

4. Грейдл​

Gradle — это инструмент управления зависимостями и автоматизации сборки, основанный на концепциях Ant и Maven.

Первое, что мы можем отметить в Gradle, это то, что он не использует XML-файлы, в отличие от Ant или Maven.

Со временем разработчики все больше и больше интересовались наличием предметно-ориентированного языка и работой с ним, что, проще говоря, позволило бы им решать проблемы в конкретной предметной области, используя язык, адаптированный для этой конкретной предметной области.

Это было принято Gradle, который использует DSL на основе Groovy или Kotlin . Это привело к уменьшению размера файлов конфигурации и уменьшению беспорядка, поскольку язык был специально разработан для решения конкретных проблем предметной области. Файл конфигурации Gradle по соглашению называется build.gradle в Groovy или build.gradle.kts в Kotlin.

Обратите внимание, что Kotlin предлагает лучшую поддержку IDE, чем Groovy, для автозаполнения и обнаружения ошибок.

Вот пример файла build.gradle для того же простого Java-проекта с основным классом HelloWorld , что и раньше:

 apply plugin: 'java'   repositories    mavenCentral()   >   jar    baseName = 'gradleExample'   version = '0.0.1-SNAPSHOT'   >   dependencies    testImplementation 'junit:junit:4.12'   > 

Мы можем скомпилировать код, запустив:

Maven против Gradle: как выбрать правильный инструмент сборки

Автоматизация сборки является важным аспектом разработки программного обеспечения. В этой статье мы сравним два самых популярных инструмента сборки для Java-разработки: Maven и Gradle.

Make и Apache Ant

Раньше разработчики использовали инструмент Make для создания проектов Java, и процесс сборки мало чем отличался от создания приложений на любом другом языке. Затем, в 2000 году, была выпущена система сборки Ant (еще один аккуратный инструмент).

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

Мейвен

Однако уже в 2004 году была предложена новая система сборки Maven, которая по-новому взглянула на процесс сборки Java-приложений. Раньше разработчики сами организовывали структуру папок для хранения исходных кодов, ресурсов, каталогов путей к классам и выходных каталогов.

И поэтому скрипты сборки Ant для двух разных приложений могли сильно отличаться: компиляция, сборка, копирование файлов в выходной каталог и т.д. прописывались отдельно. В Maven проект Java всегда имеет преднамеренно определенную структуру.

Например, исходники должны быть в src/main/java, ресурсы для тестов в src/test/resources. Maven позволяет создать файловую структуру типичного проекта с помощью одной команды. Maven также вводит понятие «жизненного цикла сборки» с последовательными фазами:

подтвердить ➞ скомпилировать ➞ проверить ➞ сделать пакет ➞ проверить ➞ установить ➞ развернуть

Теперь, благодаря фиксированной структуре папок и набору целей, нет необходимости писать и поддерживать большой скрипт сборки и скрипты сборки стали декларативными. Разработчикам стало удобнее работать не только с собственным кодом, но и со сторонними проектами, потому что понятно, как устроен исходный код и как его собирать.

В мире Java довольно много библиотек, и серьезное приложение использует их сотни. При использовании Ant необходимо самостоятельно добавить в проект необходимые jar-файлы. Вам также необходимо позаботиться о необходимых транзитивных зависимостях.

Maven предоставляет функции диспетчера зависимостей и центральный репозиторий Maven. Теперь при указании новой зависимости в скрипте сборки Maven автоматически найдет нужный jar соответствующей версии и все его транзитивные зависимости, скачает их и проследит, чтобы они попали в classpath проекта.

Вы также можете поднять свой собственный закрытый внутренний репозиторий, в котором вы можете хранить свои собственные или пропатченные библиотеки, или стандартные библиотеки, созданные вручную.

Следует отметить, что Ant можно использовать совместно с проектом Apache Ivy, который также позволяет управлять зависимостями и работать с репозиториями Maven.

Несмотря на все преимущества Maven, его декларативный подход в некоторых ситуациях может оказаться недостатком. Например, когда вам нужно изменить жизненный цикл сборки и добавить новые цели в процесс сборки.

Maven позволяет расширять его функциональность с помощью плагинов. Существует множество готовых плагинов Maven, решающих разные типовые задачи, и эти плагины также доступны из центрального репозитория.

Однако, если по каким-то причинам необходимо немного изменить стандартный жизненный цикл, а подходящего плагина нет, разработчику придется самостоятельно создавать свой плагин.

Грейдл

В 2008 году был выпущен первый релиз системы сборки Gradle, а в 2012 году вышла версия 1.0. Цель проекта Gradle — сохранить все преимущества Maven, но также дать разработчику больше возможностей для настройки процесса сборки .

Вот почему скрипты сборки Gradle написаны на Groovy DSL. Gradle предоставляет возможность писать декларативные сценарии сборки и более компактен, чем Maven, потому что XML довольно громоздкий. Также легко добавить нестандартную логику в процесс сборки в Gradle, достаточно написать Groovy-скрипт, и не нужно разрабатывать плагины.

В то же время вы можете легко отлаживать выполнение скриптов сборки, так как они представляют собой обычные файлы Groovy. Таким образом, Gradle сочетает в себе декларативный и императивный подходы. Начиная с версии 5.0, Gradle также поддерживает Kotlin DSL.

Gradle также поддерживает плагины, что позволяет разработчикам обмениваться готовыми настройками.

Также одним из существенных преимуществ Gradle является инкрементальная сборка. При перезапуске сборки Gradle определяет, изменились ли файлы, являющиеся входными данными для таргета, и если нет, то выполнение таргета пропускается, поскольку его выходные артефакты уже собраны.

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

В Gradle есть удобная функция Gradle-обертки — это возможность генерировать командные сценарии оболочки и Windows, которые автоматически загружают дистрибутив Gradle указанной версии и используют его для сборки проекта.

Это означает, что для сборки проекта Gradle вам не нужно отдельно устанавливать Gradle, достаточно просто установить Java. И также довольно легко переключить проект на другую версию Gradle.

Выбор между Maven и Gradle

Несмотря на преимущества Gradle, довольно много проектов используют систему сборки Maven. Выбор зависит от типа проекта и команды.

Maven используется с 2004 года, поэтому с ним знакомо больше разработчиков. Кроме того, Maven стабилен, последняя мажорная версия 3 была выпущена в 2010 году. Gradle уже несколько раз существенно менялся без обратной совместимости, и разработчикам приходилось переносить свои скрипты сборки на новые версии.

Кроме того, не все знакомы с Groovy или Kotlin, поэтому использование Gradle требует дополнительных знаний, тогда как Maven использует понятный XML. Поэтому возникает вопрос, если проект начал разрабатываться до того, как Gradle стал популярным, есть ли смысл переносить скрипты сборки на Gradle.

С другой стороны, все больше и больше разработчиков выбирают Gradle. Spring, Hibernate и LinkedIn используют Gradle. Кроме того, системой сборки Android является Gradle, и она популярна среди разработчиков приложений для Android.

Все популярные IDE имеют интеграцию с обеими системами сборки и поддерживают автодополнение при редактировании скриптов сборки. Как для Maven, так и для Gradle разработано огромное количество плагинов, которые позволяют добавлять часто используемые функции в процесс сборки проекта.

Заключение

Из плюсов и минусов каждой из описанных выше систем сборки можно сделать следующий вывод. Maven больше подходит для небольших проектов, не требующих настройки процесса сборки, да и время сборки проекта не так критично. Gradle больше подходит для масштабных проектов с большим количеством модулей, а также для Android-приложений.

Инструменты сборки Java: Ant против Maven против Gradle

В начале был Make как единственный доступный инструмент для сборки. Позже это было улучшено с GNU Make . Однако с тех пор наши потребности возросли, и, как следствие, эволюционировали инструменты для сборки.

В экосистеме JVM доминируют три инструмента сборки:

Муравей с плющом

Ant был первым среди «современных» инструментов сборки. Во многих отношениях он похож на Make. Он был выпущен в 2000 году и за короткий промежуток времени стал самым популярным инструментом сборки для Java-проектов. Он имеет очень низкую кривую обучения, что позволяет любому начать использовать его без какой-либо специальной подготовки. Он основан на идее процедурного программирования.

После первоначального выпуска он был улучшен возможностью принимать плагины.

Основным недостатком был XML как формат для написания скриптов сборки. XML, будучи по своей природе иерархическим, не очень подходит для процедурного подхода к программированию, который использует Ant. Другая проблема с Ant состоит в том, что его XML имеет тенденцию становиться неуправляемо большим при использовании со всеми проектами, кроме очень маленьких.

Позже, когда управление зависимостями по сети стало необходимостью, Ant принял Apache Ivy .

Основным преимуществом Ant является его контроль над процессом сборки.

специалист

Maven был выпущен в 2004 году. Его целью было улучшить некоторые проблемы, с которыми сталкиваются разработчики при использовании Ant.

Maven продолжает использовать XML в качестве формата для написания спецификации сборки. Однако структура диаметрально отличается. В то время как Ant требует от разработчиков написания всех команд, которые приводят к успешному выполнению какой-либо задачи, Maven опирается на соглашения и предоставляет доступные цели (цели), которые могут быть вызваны. В качестве дополнительного, и, вероятно, наиболее важного дополнения, Maven представил возможность загрузки зависимостей по сети (позже принятую Ant через Ivy). Это само по себе революционизировало способ поставки программного обеспечения.

Однако у Maven есть свои проблемы. Управление зависимостями плохо обрабатывает конфликты между разными версиями одной и той же библиотеки (в этом Айви гораздо лучше). XML как формат конфигурации сборки строго структурирован и стандартизирован. Настройка целей (целей) сложно. Поскольку Maven сфокусирован в основном на управлении зависимостями, сложные, настраиваемые сценарии сборки на самом деле труднее писать в Maven, чем в Ant.

Конфигурация Maven, написанная на непрерывном XML, является большой и громоздкой. В больших проектах он может содержать сотни строк кода, не делая ничего «экстраординарного».

Основным преимуществом Maven является его жизненный цикл. Пока проект основан на определенных стандартах, с Maven можно относительно легко пройти весь жизненный цикл. Это происходит за счет гибкости.

В то же время интерес к DSL (предметно-ориентированным языкам) продолжал расти. Идея состоит в том, чтобы иметь языки, предназначенные для решения проблем, относящихся к определенной области. В случае сборок одним из результатов применения DSL является Gradle.

Gradle

Gradle сочетает в себе хорошие части обоих инструментов и строит поверх них DSL и другие улучшения. Он обладает мощью и гибкостью Ant, а также жизненным циклом Maven и простотой использования. Конечным результатом является инструмент, который был выпущен в 2012 году и привлек много внимания за короткий период времени. Например, Google принял Gradle в качестве инструмента сборки по умолчанию для ОС Android.

Gradle не использует XML. Вместо этого у него был собственный DSL на основе Groovy (один из языков JVM). В результате скрипты сборки Gradle имеют тенденцию быть намного короче и понятнее, чем написанные для Ant или Maven. Объем стандартного кода намного меньше с Gradle, поскольку его DSL предназначен для решения конкретной проблемы: продвижение программного обеспечения через его жизненный цикл, от компиляции до статического анализа и тестирования до упаковки и развертывания.

Он использует Apache Ivy для JAR-зависимостей.

Усилие Gradle может быть суммировано как «условность хороша, как и гибкость».

Примеры кода

Мы создадим сценарии сборки, которые будут компилироваться, выполнять статический анализ, запускать модульные тесты и, наконец, создавать файлы JAR. Мы выполним эти операции во всех трех средах (Ant, Maven и Gradle) и сравним синтаксис. Сравнивая код для каждой задачи, мы сможем лучше понять различия и принять обоснованное решение относительно выбора инструмента для сборки.

Обо всем по порядку. Если вы сами сделаете примеры из этой статьи, вам понадобятся Ant , Ivy , Maven и Gradle . Пожалуйста, следуйте инструкциям по установке, предоставленным производителями этих инструментов. Вы можете не запускать примеры самостоятельно и вообще пропустить установку. Фрагментов кода должно быть достаточно, чтобы дать вам общее представление о том, как работает каждый из инструментов.

Репозиторий кода https://github.com/vfarcic/JavaBuildTools содержит код Java (два простых класса с соответствующими тестами), конфигурацию контрольного стиля и файлы конфигурации Ant, Ivy, Maven и Gradle.

Давайте начнем с Муравья и Айви.

Муравей с плющом

Зависимости плюща должны быть указаны в файле ivy.xml. Наш пример довольно прост и требует только зависимостей JUnit и Hamcrest.