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

«1. Введение

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

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

2. Apache Ant

Вначале 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>

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

ant compile

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

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

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

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

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

3. Apache Maven

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>baeldung</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
|   |   |       \---baeldung
|   |   |           \---maven
|   |   |                   HelloWorld.java
|   |   |                   
|   |   \---resources
|   \---test
|       +---java
|       \---resources

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

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

mvn compile

«

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

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

<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>

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

mvn package

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

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

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

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

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

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

4. Gradle

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

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

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

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

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

apply plugin: 'java'

repositories {
    mavenCentral()
}

jar {
    baseName = 'gradleExample'
    version = '0.0.1-SNAPSHOT'
}

dependencies {
    testImplementation 'junit:junit:4.12'
}

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

gradle classes

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

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

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

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

gradle copyDependencies

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

5. Заключение

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

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

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

Сейчас его используют многие проекты с открытым исходным кодом, такие как Spring. builds Он предлагает расширенные услуги анализа и отладки