Различия между Ant и Maven

Может ли кто-нибудь рассказать мне о различиях между Ant и Maven? Я никогда не пользовался. Я понимаю, что они используются для автоматизации построения Java-проектов, но я не знаю, с чего начать.

ОТВЕТЫ

Ответ 1

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

Простое сравнение

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

<project name="my-project" default="dist" basedir=".">
    <description>
        simple example build file
    </description>   
    <!-- set global properties for this build -->   
    <property name="src" location="src/main/java"/>
    <property name="build" location="target/classes"/>
    <property name="dist"  location="target"/>

    <target name="init">
      <!-- Create the time stamp -->
      <tstamp/>
      <!-- Create the build directory structure used by compile -->
      <mkdir dir="${build}"/>   
    </target>

    <target name="compile" depends="init"
        description="compile the source " >
      <!-- Compile the java code from ${src} into ${build} -->
      <javac srcdir="${src}" destdir="${build}"/>  
    </target>

    <target name="dist" depends="compile"
        description="generate the distribution" >
      <!-- Create the distribution directory -->
      <mkdir dir="${dist}/lib"/>

      <!-- Put everything in ${build} into the MyProject-${DSTAMP}.jar file
-->
      <jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
   </target>

   <target name="clean"
        description="clean up" >
     <!-- Delete the ${build} and ${dist} directory trees -->
     <delete dir="${build}"/>
     <delete dir="${dist}"/>
   </target>
 </project>

В этом простом примере Ant вы можете увидеть, как вы должны сказать Ant, что именно делать. Существует цель компиляции, которая включает задачу javac, которая компилирует исходный код в каталоге src/main/java в каталог target/classes. Вы должны указать Ant, где находится ваш источник, где вы хотите сохранить полученный байт-код, и как упаковать все это в файл JAR. Хотя есть некоторые недавние разработки, которые помогают сделать Ant менее процедурным, опыт разработчика с Ant заключается в кодировании процедурного языка, написанного в XML.

Сравните предыдущий пример Ant с примером Maven. В Maven, чтобы создать JAR файл из какого-либо источника Java, вам нужно всего лишь создать простой pom.xml, поместить исходный код в ${basedir}/src/main/java, а затем запустить mvn install из командной строки, Пример Maven pom.xml, который достигает тех же результатов.

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.sonatype.mavenbook</groupId>
  <artifactId>my-project</artifactId>
  <version>1.0</version>
</project>

Это все, что вам нужно в вашем pom.xml. Запуск mvn install из командной строки будет обрабатывать ресурсы, компилировать исходный код, выполнять модульные тесты, создавать JAR и устанавливать JAR в локальном репозитории для повторного использования в других проектах. Без изменений вы можете запустить mvn-сайт, а затем найти файл index.html в target/site, который содержит ссылки на JavaDoc и несколько отчетов о вашем исходном коде.

По общему признанию, это самый простой пример проекта. Проект, который содержит только исходный код и создает JAR. Проект, который следует за соглашениями Maven и не требует каких-либо зависимостей или настроек. Если мы хотим начать настройку поведения, наш pom.xml будет расти по размеру, а в крупнейших проектах вы можете увидеть коллекции очень сложных Maven POM, которые содержат множество настроек настройки плагина и зависимостей. Но даже когда ваши файлы POM проекта становятся более значительными, они содержат совершенно другой вид информации из файла сборки проекта с аналогичным размером, используя Ant. Maven POM содержат объявления: "Это проект JAR" и "Исходный код находится в src/main/java". Ant Файлы сборки содержат явные инструкции: "Это проект", "Источник находится в src/main/java", "Запустите javac в этом каталоге", "Поместите результаты в target/classses", "Создайте JAR из".... "и т.д. Где Ant должен был быть явным в этом процессе, для Maven было что-то" встроенное", которое просто знало, где находится исходный код и как его обрабатывать.

Сравнение на высоком уровне

Различия между Ant и Maven в этом примере? Ant...

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

Где Maven...

  • имеет соглашения, он уже знал, где был ваш исходный код, потому что вы следовали этому соглашению. Он поместил байт-код в target/classes, и он создал целевой файл JAR.
  • является декларативным. Все, что вам нужно было сделать, это создать файл pom.xml и поместить ваш источник в каталог по умолчанию. Мейвен позаботился об остальном.
  • имеет жизненный цикл, который вы вызываете при выполнении mvn install. Эта команда сказала Maven выполнить последовательность шагов последовательности, пока не достигнет жизненного цикла. Как побочный эффект этого путешествия по жизненному циклу, Maven выполнил ряд целей плагина по умолчанию, которые делали такие вещи, как компиляция и создание JAR.

Что такое Айви?

Правильно, поэтому кто-то вроде Стива Лохрена будет читать это сравнение и называть фолом. Он собирается рассказать о том, как ответ полностью игнорирует что-то по имени Айви и тот факт, что Ant может повторно использовать логику сборки в более поздних версиях Ant. Это правда. Если у вас есть куча умных людей, использующих Ant + antlibs + Ivy, вы получите хорошо спроектированную сборку, которая работает. Несмотря на это, я очень убежден в том, что Maven имеет смысл, я бы с радостью использовал Ant + Ivy с командой проекта, у которой был очень острый инженер по строительству. При этом я думаю, что в конечном итоге вы потеряете множество ценных плагинов, таких как плагин Jetty, и что в итоге вы выполните целую кучу работы, которую вам не нужно делать со временем.

Больше, чем Maven vs. Ant

  • Используется ли менеджер репозитория для отслеживания артефактов программного обеспечения. Я предлагаю загрузить Nexus. Вы можете использовать Nexus для прокси-удаленных репозиториев и предоставить место для вашей команды для развертывания внутренних артефактов.
  • У вас есть соответствующая модуляция программных компонентов. Один большой монолитный компонент редко масштабируется с течением времени. По мере развития вашего проекта вы захотите иметь концепцию модулей и подмодулей. Maven очень хорошо подходит к этому подходу.
  • Вы принимаете некоторые соглашения для своей сборки. Даже если вы используете Ant, вы должны стремиться принять какую-то форму конвенции, которая согласуется с другими проектами. Когда проект использует Maven, это означает, что любой, кто знаком с Maven, может забрать сборку и начать работать с ней, не имея необходимости возиться с конфигурацией, просто чтобы выяснить, как ее собрать.

Ответ 2

Maven - это Framework, Ant - это панель инструментов

Maven - это предварительно построенный дорожный автомобиль, тогда как Ant - это набор автомобильных деталей. С помощью Ant вам нужно построить свой собственный автомобиль, но, по крайней мере, если вам нужно сделать внедорожное вождение, вы можете построить правильный тип автомобиля.

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

XML Verbosity

tobrien - парень, который много знает о 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>

tobrien использовал свой пример, чтобы показать, что Maven имеет встроенные соглашения, но это не обязательно означает, что вы в конечном итоге пишете меньше XML. Я нашел противоположное, чтобы быть правдой. Файл pom.xml в 3 раза длиннее файла build.xml, и он не отклоняется от условных обозначений. Фактически, мой пример Maven показан без дополнительных 54 строк, необходимых для настройки плагинов. Это pom.xml для простого проекта. XML действительно начинает значительно возрастать, когда вы начинаете добавлять дополнительные требования, что не является чем-то необычным для многих проектов.

Но вы должны сказать Ant, что делать

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

Это правда, это сэкономит мне время, если я не буду явно писать эти цели Ant. Но сколько времени? Общий файл сборки, который я использую сейчас, - это тот, который я написал 5 лет назад с небольшими уточнениями с тех пор. После моего 2-летнего эксперимента с Maven я вытащил старый файл сборки Ant из шкафа, вычистил его и вернул на работу. Для меня стоимость того, чтобы явно указывать Ant, что делать, добавила менее чем за неделю в течение 5 лет.

Сложность

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

По сравнению с Ant, разработчик проекта Maven потратит больше времени:

  • Документация для чтения: на Maven имеется гораздо больше документации, потому что вам нужно гораздо больше узнать.
  • Обучение членов команды: им легче спросить кого-то, кто знает, а не пытаться найти ответы сами.
  • Устранение неполадок сборки: Maven менее надежна, чем Ant, особенно для неосновных плагинов. Кроме того, сборки Maven не повторяются. Если вы зависите от версии плагина SNAPSHOT, что очень вероятно, ваша сборка может сломаться, если вы ничего не изменили.
  • Написание плагинов Maven: плагины обычно записываются с учетом конкретной задачи, например. создать пакет webstart, что затрудняет повторное использование их для других задач или для их сочетания для достижения цели. Таким образом, вам может потребоваться написать один из ваших собственных обходных разрывов в существующем наборе плагинов.

Напротив:

  • Ant документация краткая, всеобъемлющая и все в одном месте.
  • Ant прост. Новый разработчик, пытающийся изучить Ant, должен понимать несколько простых понятий (целей, задач, зависимостей, свойств), чтобы иметь возможность выяснить остальную часть того, что им нужно знать.
  • Ant является надежным. За последние несколько лет не было очень много выпусков Ant, потому что они уже работают.
  • Ant сборки повторяемы, потому что они, как правило, создаются без каких-либо внешних зависимостей, таких как онлайн-репозитории, экспериментальные сторонние плагины и т.д.
  • Ant является исчерпывающим. Поскольку это инструментарий, вы можете комбинировать инструменты для выполнения практически любой задачи. Если вам когда-либо понадобится написать свою собственную задачу, это очень просто сделать.

Дружественные

Другим отличием является знакомство. Новые разработчики всегда требуют времени, чтобы ускориться. Знакомство с существующими продуктами помогает в этом отношении, и сторонники Maven справедливо утверждают, что это преимущество Maven. Разумеется, гибкость Ant означает, что вы можете создавать любые соглашения, которые вам нравятся. Таким образом, конвенция, которую я использую, заключается в том, чтобы поместить мои исходные файлы в имя каталога src/main/java. Мои скомпилированные классы переходят в каталог с именем target/classes. Звучит знакомо, не так ли.

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

Ответ 3

Ant - это в основном инструмент построения.

Maven - это инструмент управления проектами и зависимостями (который, конечно же, создает и ваш проект).

Ant + Ivy - довольно хорошая комбинация, если вы хотите избежать Maven.

Ответ 4

Maven или Ant? - очень похожий вопрос на этот вопрос, который должен помочь вам ответить на ваши вопросы.

Что такое Maven? на официальном сайте.

edit:. Для нового проекта/проекта greenfield я бы рекомендовал использовать Maven: "соглашение по конфигурации" сохранит вам достойный кусок времени в письменной форме и установит сценарии сборки и развертывания. Когда вы используете ant, сборка script имеет тенденцию расти со временем по длине и сложности. Для существующих проектов может быть сложно отнести их конфигурацию/компоновку в систему Maven.

Ответ 5

Просто перечислите некоторые отличия:

  • Ant не имеет формальных соглашений. Вы должны сказать Ant, где именно найти источник, куда поместить выходы и т.д.
  • Ant является процедурным. Вы должны сказать Ant, что именно делать; скажите ему, чтобы скомпилировать, скопировать, затем сжать и т.д.
  • Ant не имеет жизненного цикла.
  • Maven использует условные обозначения. Он знает, где ваш исходный код будет автоматически, если вы будете следовать этим соглашениям. Вам не нужно сообщать Maven, где он находится.
  • Maven является декларативным; Все, что вам нужно сделать, это создать файл pom.xml и поместить ваш источник в каталог по умолчанию. Maven позаботится обо всем остальном.
  • Maven имеет жизненный цикл. Вы просто вызываете mvn install и выполняете последовательность шагов последовательности.
  • У Maven есть своя информация об общих задачах проекта. Для запуска тестов просто выполните mvn-тест, если файлы находятся по умолчанию. В Ant вам сначала нужно будет JUnit JAR файл, а затем создать путь к классу, который включает JUnit JAR, а затем сообщить Ant, где он должен искать исходный код теста, написать цель, которая компилирует исходный код, а затем, наконец, выполните единичные тесты с помощью JUnit.

Update:

Это произошло от Maven: окончательное руководство. Извините, я полностью забыл процитировать его.

Ответ 6

Maven действует как инструмент управления зависимостями - его можно использовать для извлечения банок из центрального репозитория или из репозитория, который вы создали, и как инструмент декларативной сборки. Разница между "декларативным" инструментом сборки и более традиционным, например ant или make, заключается в том, что вы настраиваете то, что нужно сделать, а не как это делается. Например, вы можете сказать в maven script, что проект должен быть упакован как WAR файл, а maven знает, как с этим справиться.

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

Вы также должны иметь в виду, что есть плагин для запуска команд ant из maven:

http://maven.apache.org/plugins/maven-ant-plugin/

Кроме того, архетипы maven позволяют быстро начать работу над проектом. Например, есть архетип Wicket, который предоставляет команду maven, которую вы запускаете, чтобы получить целый, готовый к запуску проект hello world-type.

https://wicket.apache.org/start/quickstart.html

Ответ 7

Я могу взять человека, который никогда не видел Ant - его build.xml достаточно хорошо написаны, и они могут понять, что происходит. Я могу взять того же человека и показать им Maven POM, и они не будут знать, что происходит.

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

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

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

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

Ответ 8

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

Ответ 9

В Maven также расположено большое хранилище широко используемых проектов с открытым исходным кодом. Во время сборки Maven может загружать эти зависимости для вас (а также зависимости ваших зависимостей:)), чтобы сделать эту часть построения проекта более управляемой.