Maven gradle ant что это

Maven vs Gradle? Это неправильная постановка вопроса

Написать, наконец, этот пост меня заставила уже давняя дискуссия вот к этому посту на тему, которая время от времени всплывает то там, то тут.

Я много раз имел возможность убедиться, что далеко не все одинаково понимают, в чем же состоит декларативность vs процедурность той или иной системы сборки. Основным достоинством инструмента сборки зачастую считается возможность писать алгоритмы сборки на удобном языке. Нужен DSL, никуда без него.

В gradle этот DSL базируется на groovy. sbt использует скалу, leiningen — Clojure, Ant использует xml (совершенно не по делу, кстати). Несложно припомнить системы сборки на базе javascript. Каждый собирает на том языке, который ему ближе. И новые инструменты пишут, например, на котлине.

Увы, но наличие DSL совсем не означает декларативности. Скорее наоборот. В итоге, gradle проект вообще не может полноценно жить без pom.xml. Это шутка, но с большой долей правды. Посмотрите вот сюда: это репозиторий.

Что у нас тут лежит? Да-да, именно pom.xml, он самый. А где же у нас build.gradle? А нет его. Понимаете? Его тут нет.

То есть все метаданные, которые предоставлены о собранном проекте, который заметим, собирается при помощи gradle, состоят только и исключительно из метаданных maven.

Вас это не удивляет? Меня — нисколько. На мой взгляд, gradle, sbt, leiningen и многие другие инструменты почти (или вовсе) не предоставляют метаданных в доступном другим продуктам виде.

Они реально видны только самим себе, и только изнутри процесса сборки. Просто потому, что скрипт сборки — это груви код (Clojure, скала, javascript). Именно поэтому же их так плохо поддерживают IDE (в сравнении с maven или ant, где скрипт это xml). Чтобы понять, что там происходит, нужно выполнить. Нужно иметь gradle внутри, и нужно чтобы gradle отдавал в IDE необходимую информацию.

Как я вижу себе декларативность, и зачем она бывает нужна? В качестве иллюстрации приведу два своих проекта, и один от apache:

• Начнем пожалуй с Apache Karaf. В ssh-консоли вам доступна команда установки модуля (OSGI-bundle). Эта команда использует не что иное, как координаты модуля в maven repository: bundle:install mvn:groupId/artifactId/version. При этом самого maven karaf не содержит — под капотом ничто иное, как Aether, плюс обертка над ним (Pax URL).
• Аналогичную конструкцию я реализовал когда-то давно на Jython, и работала она внутри Weblogic. Использовался тот же Aether, плюс WLST API. И позволяло все это автоматически обновлять установленные в контейнере JavaEE модули, разыскивая их новые версии в репозитории.
  Опять же — maven в конструкцию не входил. Использовались репозиторий, Aether, и pom.xml, которые maven упаковывает в META-INF модуля.
• И последний пример. В моей практике был один maven plugin, который в качестве исходных данных для своей работы использовал SVN, сканируя папки и файлы на предмет изменений в проектах, сравнивая их с bug tracker, и принимая решения, какие именно собранные артифакты нужно включать в релиз, и деплоить.

Во-первых, мы видим, что с описанием проекта (в моем случае это всегда был pom.xml) иногда бывает нужно и можно работать из любого достаточно развитого языка. Это не обязан быть инструмент сборки, на который изначально расчитан проект.

Во-вторых, если репозиторий спроектирован правильно, в соответствии с принципами REST, то нам не нужен никакой специальный софт для работы с ним, кроме http-сервера. Нужны только данные метауровня чуть выше проекта (список доступных версий, например).

В-третьих, очень удобно то, что важная часть инфраструктуры, в нашем случае plugins, сами просто обычные артефакты, лежат в том же репозитории, и никак не связаны вообще с конкретным проектом.

Вот это я называю декларативным подходом. У нас есть проекты, их много. Они бывают в репозитории, в виде собранных артефактов, в VCS, и еще где-либо, и могут обрабатываться разными инструментами — а не только одним единственным. Дескриптор проекта — это просто файл, любого стандартного и удобного для обработки формата. Репозиторий артефактов — это тоже стандартизованный формат + простой REST API. А логика сборки, на любом удобном вам DSL, лежит отдельно. Хотите — в самом дескрипторе, хотите — в репозитории.

Как бы я вообще это все сделал? В сущности, если брать за основу maven, то сейчас тут не хватает гибкости в части plugins, их настроек, и т.п., потому что существующий xml — это сериализованное представление java-модели данных plugins и ядра, и оно не гибко. Если разработчики решили, что какие-то данные о проекте вам не нужны — у вас остается только вариант key-value в виде properties.

А следовало бы сделать нечто произвольной, но регулярной структуры, ну скажем типа RDF (не обязательно именно его).
Описание проекта в виде RDF сразу позволяет делать полезные вещи вроде поиска в нем, как в базе данных (т.е. репозиторий, в части метаданных, становится просто SPARQL endpoint, и умеет отвечать на поисковые запросы). И такие же запросы можно строить применительно к проекту.

Вот это и был бы истинный poliglot maven. Причем это, кстати, выглядит вполне реализуемо, даже в рамках существующей инфраструктуры.

Муравей против 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'   > 

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

Инструменты сборки 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.

Gradle в сравнении с Maven: Производительность, совместимость, сборка и многое другое

Gradle — один из нескольких инструментов разработки Java, представленных во всеобщем руководстве разработчика Java от Stackify, но это не единственный инструмент автоматизации сборки, который следует рассмотреть. Maven — более старая и часто используемая альтернатива, но какая система сборки лучше всего подходит для вашего проекта? Поскольку другие инструменты, такие как Spring, позволяют разработчикам выбирать между этими двумя системами, в сочетании с растущим числом интеграций для обеих, решение в значительной степени зависит от вас.

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

Что такое Gradle?

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

Несколько разработчиков создали Gradle и впервые выпустили его в 2007 году, а в 2013 году он был принят компанией Google в качестве системы сборки для проектов Android. Она была разработана для поддержки многопроектных больших сборок. Она также позволяет дополнять вашу сборку, поскольку знает, какие части вашего проекта обновляются. Задачи, которые зависят от обновленных частей повторно не выполняются. На данный момент последним стабильным релизом является версия 3.4, которая была выпущена в феврале 2017 года. Она поддерживает разработку и последующее развертывание с использованием Java, Scala и Groovy, а в будущем будут представлены другие рабочие процессы и языки.

Что такое Maven?

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

Maven загружает библиотеки и плагины из различных репозиториев, а затем помещает их все в кэш на вашей локальной машине. Хотя Maven преимущественно используется для проектов на Java, вы можете использовать его для Scala, Ruby и C#, а также для множества других языков.

Gradle в сравнении с Maven

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

С точки зрения производительности, обе программы позволяют параллельно выполнять многомодульные сборки. Однако Gradle позволяет выполнять инкрементные сборки, поскольку проверяет, какие задачи обновлены, а какие нет. Если это так, то задача не выполняется, что дает вам гораздо меньшее время сборки. Другие отличительные особенности производительности, которые можно найти в Gradle, включают:

• Инкрементная компиляция для классов Java
• Избегание компиляции для Java
• Использование API для инкрементальных подзадач
• Демон компилятора, который также значительно ускоряет компиляцию.

Что касается управления зависимостями, то и Gradle, и Maven могут работать с динамическими и переходными зависимостями, использовать сторонние кэши зависимостей и читать формат метаданных POM. Вы также можете объявлять версии библиотек через центральное определение версий и обеспечивать централизованное версионирование. Оба продукта загружают переходные зависимости из своих репозиториев артефактов. Maven имеет Maven Central, а Gradle — JCenter, кроме того, вы можете определить свой собственный репозиторий компании. Если требуется несколько зависимостей, Maven может загружать их одновременно.

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

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

• Использование правил подстановки для совместимых библиотек
• Использование правил ReplacedBy
• Более качественное управление метаданными
• Возможность динамической замены проектных зависимостей на внешние и наоборот.

Gradle также облегчает работу с составными сборками, позволяя работать со специальными и постоянными составными сборками, а также объединять различные сборки и импортировать составную сборку в Eclipse или IntelliJ IDEA.

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

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

Примеры кода

В сравнении Ant, Gradle и Maven Нареш Джоши сравнивает код, необходимый для создания сценария сборки, который компилирует, выполняет статический анализ, запускает модульные тесты и создает JAR-файлы на сайте Programming Mitra.

Вот код, необходимый для достижения этой цели с помощью Maven:

 4.0.0 com.programming.mitra java-build-tools jar 1.0  junit junit 4.11     org.apache.maven.plugins maven-compiler-plugin 2.3.2    

Чтобы запустить задачу Maven, создающую JAR-файл, выполните следующее:

mvn package

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

 org.apache.maven.plugins maven-checkstyle-plugin 2.12.1   config/checkstyle/checkstyle.xml true true  check     org.codehaus.mojo findbugs-maven-plugin 2.5.4   check     org.apache.maven.plugins maven-pmd-plugin 3.1   check    

Чтобы запустить задачу для достижения этой цели, выполните следующее:

mvn verify

Для выполнения некоторых основных и общих задач требуется довольно много XML-кода, и по этой причине проекты в Maven с большим количеством задач и зависимостей могут привести к файлам pom.xml, состоящим из сотен и тысяч строк кода.

Для сравнения, вот пример кода build.gradle , который достигает аналогичного результата:

apply plugin:'java' apply plugin:'checkstyle' apply plugin:'findbugs' apply plugin:'pmd' version ='1.0' repositories < mavenCentral() >dependencies

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

gradle tasks --all

Как выбрать?

В целом, оба инструмента имеют свои сильные и слабые стороны.

• Индивидуальные сборки. С помощью Maven вы можете легко определить метаданные и зависимости вашего проекта, но создание очень индивидуальной сборки может стать кошмаром для пользователей Maven. Файл POM может легко раздуться по мере роста проекта и впоследствии превратиться в нечитаемый XML-файл.

• Управление зависимостями и структура каталогов. Тем не менее, Maven обеспечивает простое, но эффективное управление зависимостями, а поскольку он имеет структуру каталогов для ваших проектов, у вас есть своего рода стандартная схема для всех ваших проектов. Он использует декларативный XML-файл для своего POM-файла и имеет множество плагинов, которые вы можете использовать. Gradle использует структуру каталогов, которую вы видите в Maven, но она может быть настроена. Он также использует тот же формат GAV, который Maven использует для идентификации артефактов.

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

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

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

Дополнительные ресурсы и обучающие материалы по Gradle и Maven

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

• The Gradle build system- Tutorial
• Getting Started With Gradle
• Maven in 5 Minutes
• Maven for building Java applications – Tutorial
• Maven Tutorial

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

• Блог компании OTUS
• Тестирование веб-сервисов
• Gradle