Различия между Муравьем и Мавеном [закрыто]

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

В Maven: «Полное руководство» я писал о различиях между 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 site и затем найти файл index.html в target / site, который содержит ссылки на JavaDoc и несколько отчетов о вашем исходном коде.

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

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

Различия между Муравьем и Мавеном в этом примере? Муравей...

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

Где Мейвен ...

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

А как насчет Айви?

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

Важнее, чем Maven против Ant

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

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.

Муравей в основном строительный инструмент.

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

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

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

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

Обновить:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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