Ant срещу Maven срещу Gradle

Програмиране
Тази статия е част от поредица: • Въведение в Gradle

• Ant срещу Maven срещу Gradle (текуща статия) • Писане на потребителски приставки Gradle

• Създаване на дебел буркан в 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 и е достатъчно прост, за да може всеки да започне да го използва без особени предпоставки. Файловете за изграждане на мравки са написани в XML и по правило те се наричат build.xml .

Различните фази на процеса на изграждане се наричат ​​„цели“.

Ето пример за файл build.xml за прост Java проект с основния клас HelloWorld :

Този файл за изграждане дефинира четири цели: почистване , компилиране , jar и стартиране . Например, можем да компилираме кода, като стартираме:

ant compile

Това първо ще задейства чистата цел, която ще изтрие директорията „класове“. След това целевата компилация ще пресъздаде директорията и ще компилира папката 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 от преди:

 4.0.0 baeldung mavenExample 0.0.1-SNAPSHOT Maven example   junit junit 4.12 test

Сега обаче структурата на проекта също е стандартизирана и отговаря на конвенциите на Maven:

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

За разлика от Ant, няма нужда да дефинирате всяка от фазите в процеса на изграждане ръчно. Вместо това можем просто да извикаме вградените команди на Maven.

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

mvn compile

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

Един от наличните плъгини е Apache Maven Dependency Plugin, който има за цел да зависи от копиране, който ще копира нашите зависимости в определена директория.

За да покажем този плъгин в действие, нека включим този плъгин в нашия файл pom.xml и конфигурираме изходна директория за нашите зависимости:

   org.apache.maven.plugins maven-dependency-plugin   copy-dependencies package  copy-dependencies   target/dependencies

Този плъгин ще бъде изпълнен на фаза на пакета , така че ако изпълним :

mvn package

Ще изпълним този плъгин и ще копираме зависимости в папката target / зависимостите.

Съществува и статия за това как да създадете изпълним JAR, използвайки различни плъгини Maven. Освен това, за подробен преглед на Maven, разгледайте това основно ръководство за Maven, където са разгледани някои ключови характеристики на Maven.

Maven стана много популярен, тъй като компилационните файлове вече бяха стандартизирани и отнемаше значително по-малко време за поддържане на компилираните файлове в сравнение с Ant. Въпреки това, макар и по-стандартизирани от Ant файловете, конфигурационните файлове на Maven все още са склонни да стават големи и тромави.

Строгите конвенции на 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

At its core, Gradle intentionally provides very little functionality. Plugins add all useful features. In our example, we were using java plugin which allows us to compile Java code and other valuable features.

Gradle gave its build steps name “tasks”, as opposed to Ant's “targets” or Maven's “phases”. With Maven, we used Apache Maven Dependency Plugin, and it's a specific goal to copy dependencies to a specified directory. With Gradle, we can do the same by using tasks:

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

We can run this task by executing:

gradle copyDependencies

5. Conclusion

In this article, we presented Ant, Maven, and Gradle – three Java build automation tools.

Not surprisingly, Maven holds the majority of the build tool market today.

Gradle обаче е забелязал добро приемане в по-сложни кодови бази поради следните причини:

  • Много проекти с отворен код, като Spring, го използват сега
  • Той е по-бърз от Maven за повечето сценарии, благодарение на своите постепенни компилации
  • Той предлага усъвършенствани услуги за анализ и отстраняване на грешки

Изглежда обаче, че Gradle има по-стръмна крива на обучение, особено ако не сте запознати с Groovy или Kotlin.

Напред » Писане на потребителски приставки Gradle « Предишно въведение в Gradle