Maven - це Рамка, Мураха - це інструментарій
Maven - це попередньо побудований дорожній автомобіль, тоді як Ant - це набір автомобільних деталей. З Ant ви повинні побудувати свій власний автомобіль, але принаймні, якщо вам потрібно зробити позашляховик, ви зможете побудувати правильний тип автомобіля.
Інакше кажучи, Maven - це рамка, а Ant - це інструментарій. Якщо ви задоволені роботою в рамках, то Мейвен буде добре. Проблема для мене полягала в тому, що я постійно натикався на межі рамки, і це не дозволило мені вийти.
XML Verbosity
tobrien - це хлопець, який багато що знає про Мейвена, і я думаю, що він забезпечив дуже гарне, чесне порівняння двох продуктів. Він порівнював простий Maven pom.xml з простим файлом збірки мурашок і згадував, як проекти Maven можуть стати складнішими. Я думаю, що варто поглянути на порівняння пари файлів, які ви, швидше за все, побачите в простому реальному проекті. Файли, представлені нижче, представляють один модуль у складі багатомодуля.
По-перше, файл Maven:
<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/maven-4_0_0.xsd">
<parent>
<groupId>com.mycompany</groupId>
<artifactId>app-parent</artifactId>
<version>1.0</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>persist</artifactId>
<name>Persistence Layer</name>
<dependencies>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>common</artifactId>
<scope>compile</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>com.mycompany</groupId>
<artifactId>domain</artifactId>
<scope>provided</scope>
<version>${project.version}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernate.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>${commons-lang.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>${spring.version}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.dbunit</groupId>
<artifactId>dbunit</artifactId>
<version>2.2.3</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>${testng.version}</version>
<scope>test</scope>
<classifier>jdk15</classifier>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>${commons-dbcp.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>${oracle-jdbc.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.easymock</groupId>
<artifactId>easymock</artifactId>
<version>${easymock.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
І еквівалентний файл Ant:
<project name="persist" >
<import file="../build/common-build.xml" />
<path id="compile.classpath.main">
<pathelement location="${common.jar}" />
<pathelement location="${domain.jar}" />
<pathelement location="${hibernate.jar}" />
<pathelement location="${commons-lang.jar}" />
<pathelement location="${spring.jar}" />
</path>
<path id="compile.classpath.test">
<pathelement location="${classes.dir.main}" />
<pathelement location="${testng.jar}" />
<pathelement location="${dbunit.jar}" />
<pathelement location="${easymock.jar}" />
<pathelement location="${commons-dbcp.jar}" />
<pathelement location="${oracle-jdbc.jar}" />
<path refid="compile.classpath.main" />
</path>
<path id="runtime.classpath.test">
<pathelement location="${classes.dir.test}" />
<path refid="compile.classpath.test" />
</path>
</project>
Тобріен використав свій приклад, щоб показати, що Maven має вбудовані конвенції, але це не обов'язково означає, що ви закінчуєте писати менше XML. Я вважав, що навпаки є правдою. Pom.xml в 3 рази довший, ніж build.xml, і це не відхиляється від умов. Насправді, мій приклад Maven показаний без зайвих 54 рядків, необхідних для налаштування плагінів. Цей pom.xml призначений для простого проекту. XML дійсно починає значно зростати, коли ви починаєте додавати додаткові вимоги, що не є звичайним для багатьох проектів.
Але ти мусиш сказати Мураві, що робити
Мій приклад Мураха вище не звичайно. Нам залишається визначити цілі, які використовуються для очищення, компіляції, тестування тощо. Вони визначаються у загальному файлі збірки, який імпортується всіма модулями в мультимодульному проекті. Що призводить мене до того, що всі ці речі повинні бути чітко написані в Ant, тоді як це декларативне в Maven.
Це правда, це заощадило б мені час, якби мені не довелося чітко писати ці мурашині цілі. Але скільки часу? Поширений файл збірки, який я зараз використовую, - це той, який я написав 5 років тому, з тих пір лише з невеликими уточненнями. Після 2-річного експерименту з Мейвен я витягнув з шафи старий файл збирання мурашок, запилив його та повернув на роботу. Для мене вартість того, щоб явно сказати Мураві, що робити, склала менше ніж тиждень протягом 5 років.
Складність
Наступна основна відмінність, яку я хотів би зазначити, полягає у складності та реальному ефекті. Maven був побудований з метою зменшити завантаженість розробників, на які покладено завдання створення та управління процесами збирання. Для цього це має бути складним. На жаль, складність, як правило, заперечує поставлену мету.
Якщо порівнювати з Ant, хлопець з будівництва на проект Maven витратить більше часу:
- Читання документації: На Maven набагато більше документації, тому що є так багато більше, що потрібно вчитися.
- Виховання членів команди: їм легше запитати когось, хто знає, а не намагатися знайти відповіді самі.
- Виправлення неполадок у складанні: Maven менш надійний, ніж Ant, особливо непрофільні плагіни. Також побудови Maven не повторюються. Якщо ви залежите від версії плагіна SNAPSHOT, що дуже ймовірно, ваша збірка може зламатися, не змінивши нічого.
- Написання плагінів Maven: Плагіни, як правило, записуються з певним завданням, наприклад, створити пакет веб-стартів, що ускладнює повторне використання їх для виконання інших завдань або їх поєднання для досягнення мети. Таким чином, можливо, вам доведеться записати один із власних прогалин у існуючий набір плагінів.
У контрасті:
- Документація щодо мурашок є стислою, вичерпною і все в одному місці
- Мураха проста. Новому розробнику, який намагається навчитися Ant, потрібно лише зрозуміти кілька простих понять (цілі, завдання, залежності, властивості), щоб мати можливість з'ясувати решту того, що їм потрібно знати.
- Мураш надійний. За останні кілька років не було дуже багато випусків Ant, тому що це вже працює.
- Набори мурашок повторюються, оскільки вони, як правило, створюються без зовнішніх залежностей, таких як онлайн-сховища, експериментальні сторонні додатки тощо.
- Мураха всеосяжна. Оскільки це панель інструментів, ви можете комбінувати інструменти для виконання практично будь-якого завдання, яке вам потрібно. Якщо вам коли-небудь потрібно написати власне завдання, це зробити дуже просто.
Ознайомлення
Ще одна відмінність полягає у знайомстві. Новим розробникам завжди потрібен час, щоб досягти швидкості. Ознайомлення з існуючими продуктами допомагає в цьому плані, і прихильники Maven справедливо стверджують, що це користь Maven. Звичайно, гнучкість Мурахи означає, що ви можете створювати будь-які звичаї. Таким чином, умова, яку я використовую, полягає в тому, щоб помістити свої вихідні файли в ім'я каталогу src / main / java. Мої складені класи переходять до каталогу з назвою target / класів. Звучить знайомо, чи не так.
Мені подобається структура каталогів, яку використовує Maven. Я думаю, що це має сенс. Також їх життєвий цикл будувати. Тому я використовую ті самі умовності у своїх побудовах Ant. Не тільки тому, що це має сенс, а тому, що він буде знайомий кожному, хто раніше використовував Maven.