Перейти к основному содержимому

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

· 7 мин. чтения

1. Введение​

В этой статье мы рассмотрим три инструмента автоматизации сборки 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.0</modelVersion>
    <groupId>foreach</groupId>
    <artifactId>mavenExample</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <description>Maven example</description>

    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </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.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <executions>
                <execution>
                    <id>copy-dependencies</id>
                    <phase>package</phase>
                    <goals>
                        <goal>copy-dependencies</goal>
                    </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'
}

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

gradle classes

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

Gradle дал своим шагам сборки название «задачи», в отличие от «целей» Ant или «фаз» Maven. С Maven мы использовали подключаемый модуль Apache Maven Dependency Plugin, и его конкретной целью является копирование зависимостей в указанный каталог. С Gradle мы можем сделать то же самое, используя задачи:

task copyDependencies(type: Copy) {
   from configurations.compile
   into 'dependencies'
}

Мы можем запустить эту задачу, выполнив:

gradle copyDependencies

5. Вывод​

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

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

Однако Gradle хорошо зарекомендовал себя в более сложных кодовых базах по следующим причинам:

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

Однако у Gradle более крутая кривая обучения, особенно если вы не знакомы с Groovy или Kotlin.