Maven - это фреймворк, Ant - набор инструментов
Maven - это готовый дорожный автомобиль, тогда как Ant - это комплект автомобильных деталей. С Ant вы должны построить свой собственный автомобиль, но, по крайней мере, если вам нужно будет ездить по бездорожью, вы можете построить правильный тип автомобиля.
Другими словами, Maven - это фреймворк, а Ant - набор инструментов. Если вы довольны работой в рамках фреймворка, то с Maven все будет в порядке. Проблема для меня заключалась в том, что я продолжал сталкиваться с рамками фреймворка, и он меня не выпускал.
XML многословие
Тобриен - парень, который много знает о Maven, и я думаю, что он дал очень хорошее, честное сравнение двух продуктов. Он сравнил простой Maven pom.xml с простым файлом сборки Ant и упомянул, как проекты 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 выше не завершен, конечно. Нам все еще нужно определить цели, используемые для очистки, компиляции, тестирования и т. Д. Они определены в общем файле сборки, который импортируется всеми модулями в многомодульном проекте. Что приводит меня к вопросу о том, как все эти вещи должны быть явно написаны на Ant, тогда как это декларативно в Maven.
Это правда, это сэкономило бы мне время, если бы мне не пришлось явно писать эти цели Ant. Но сколько времени? Общий сборочный файл, который я сейчас использую, - это тот, который я написал 5 лет назад, но с тех пор внес лишь небольшие изменения. После двухлетнего эксперимента с Maven я вытащил старый файл сборки Ant из шкафа, вычистил его и вернул к работе. Для меня стоимость явного указания Ant, что делать, составила менее недели в течение 5 лет.
сложность
Следующее важное отличие, которое я хотел бы упомянуть, - это сложность и реальный эффект, который он имеет. Maven был создан с целью уменьшить нагрузку на разработчиков, которым поручено создавать и управлять процессами сборки. Чтобы сделать это, оно должно быть сложным. К сожалению, эта сложность имеет тенденцию сводить на нет их намеченную цель.
По сравнению с Ant, сборщик проекта Maven будет тратить больше времени:
- Чтение документации: документации по Maven гораздо больше, потому что вам нужно многому научиться.
- Обучение членов команды: им легче спрашивать кого-то, кто знает, чем пытаться найти ответы самостоятельно.
- Устранение неполадок сборки: Maven менее надежен, чем Ant, особенно неосновные плагины. Кроме того, сборки Maven не повторяются. Если вы зависите от версии плагина SNAPSHOT, что весьма вероятно, ваша сборка может сломаться, если вы ничего не изменили.
- Написание плагинов Maven. Плагины обычно пишутся с конкретной задачей, например, для создания пакета веб-запуска, что затрудняет их повторное использование для других задач или объединение их для достижения цели. Таким образом, вам, возможно, придется написать один из собственных пробелов в существующем наборе плагинов.
Напротив:
- Ant документация краткая, полная и все в одном месте.
- Муравей прост. Новому разработчику, пытающемуся изучить Ant, нужно только понять несколько простых понятий (цели, задачи, зависимости, свойства), чтобы понять остальную часть того, что им нужно знать.
- Муравей надежен. За последние несколько лет не было очень много выпусков Ant, потому что он уже работает.
- Сборки Ant повторяемы, потому что они обычно создаются без каких-либо внешних зависимостей, таких как онлайн-репозитории, экспериментальные сторонние плагины и т. Д.
- Муравей всеобъемлющий. Поскольку это набор инструментов, вы можете комбинировать инструменты для выполнения практически любой задачи, которую вы хотите. Если вам когда-нибудь понадобится написать собственное задание, это очень просто сделать.
фамильярность
Другое отличие - это знакомство. Новым разработчикам всегда требуется время, чтобы набрать скорость. В этом отношении помогает знакомство с существующими продуктами, и сторонники Maven справедливо утверждают, что это является преимуществом Maven. Конечно, гибкость Ant означает, что вы можете создавать любые соглашения, которые вам нравятся. Поэтому я использую соглашение, которое помещает мои исходные файлы в каталог с именем src / main / java. Мои скомпилированные классы попадают в каталог с именем target / classes. Звучит знакомо, не правда ли?
Мне нравится структура каталогов, используемая Maven. Я думаю, что это имеет смысл. Также их жизненный цикл сборки. Поэтому я использую те же соглашения в своих сборках Ant. Не только потому, что это имеет смысл, но и потому, что оно будет знакомо любому, кто раньше использовал Maven.