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

Используйте FileReader для кодирования изображения в качестве URL-адреса данных:

jQuery.ajax({...})
.done(function (r) {
  var reader = new FileReader(
  reader.onload = (function(self) {
    return function(e) {
      document.getElementById("img").src = e.target.result;
    }
  })(this);
  reader.readAsDataURL(new Blob([r]));
});
178
задан Ludwig Weinzierl 30 May 2009 в 09:52
поделиться

9 ответов

Муравей является главным образом инструментом сборки.

Знаток является проектом и инструментом управления зависимостей (который, конечно, разрабатывает Ваш проект также).

Муравей + Ivy является довольно хорошей комбинацией, если Вы хотите избежать Знатока.

20
ответ дан cherouvim 4 November 2019 в 15:54
поделиться

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

, Кто такой Знаток? на официальном сайте.

редактирование: Для нового / проекта нового строительства, я рекомендовал бы использовать Знатока: "конвенция по конфигурации" сохранит Вас достойный блок времени в письменной форме и настраивающий сценарии развертывания и сборка. При использовании муравья сценарий сборки имеет тенденцию расти со временем в длине и сложности. Для существующих проектов это может быть твердо к рожку для обуви их конфигурация/расположение в систему Знатока.

17
ответ дан Community 4 November 2019 в 15:54
поделиться

Только перечислить еще некоторые различия:

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

Обновление:

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

16
ответ дан Ascalonian 4 November 2019 в 15:54
поделиться

Знаток действует как оба инструмент управления зависимости - он может использоваться для получения банок от центрального репозитория или из репозитория, который Вы открываете - и как декларативный инструмент сборки. Различие между "декларативным" инструментом сборки и более традиционным как муравей или делает, Вы, настраивают, какие потребности быть сделанным, не, как это сделано. Например, можно сказать в сценарии знатока, что проект должен быть упакован как ВОЕННЫЙ файл, и знаток знает, как обработать это.

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

необходимо также иметь в виду, что существует плагин для рабочих команд муравья из знатока:

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

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

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

14
ответ дан James Kingsbery 4 November 2019 в 15:54
поделиться

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

6
ответ дан karlipoppins 4 November 2019 в 15:54
поделиться

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

4
ответ дан markt 4 November 2019 в 15:54
поделиться

В Знатоке: Полное руководство, я записал о различиях между Знатоком и Муравьем во введении, заголовок раздела является "Различиями Между Муравьем и Знатоком". Вот ответ, который является комбинацией информации в том введении с некоторыми дополнительными примечаниями.

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

Я только показываю Вам это для иллюстрирования идеи, что на наиболее базовом уровне у Знатока есть встроенные конвенции. Вот простой файл типа "build" Муравья:

<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>

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

Контрастируйте предыдущий пример Муравья с примером Знатока. В Знатоке, для создания файла JAR из некоторого источника Java все, что необходимо сделать, создают простой pom.xml, помещают исходный код в $ {basedir}/src/main/java и затем выполняют установку mvn из командной строки. 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 установка из командной строки обработает ресурсы, скомпилировать источник, выполнить модульные тесты, создать JAR и установить JAR в локальном репозитории для повторного использования в других проектах. Без модификации можно выполнить mvn сайт и затем найти файл index.html в цели/сайте, которая содержит ссылки на JavaDoc и несколько отчетов об исходном коде.

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

Высокоуровневое сравнение

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

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

Где знаток...

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

Что относительно плюща?

Право, таким образом, кто-то как Steve Loughran собирается считать то сравнение и фол вызова. Он собирается говорить о том, как ответ полностью игнорирует что-то названное Ivy и тем, что Муравей может снова использовать логику сборки в более свежих выпусках Муравья. Это верно. Если у Вас будет набор умных людей, использующих Муравья + antlibs + Ivy, то Вы закончите с хорошо разработанной сборкой, которая работает. Даже при том, что, я очень убежден, что Знаток имеет смысл, я счастливо использовал бы Муравья + Ivy с проектной группой, которая имела очень резкого инженера сборки. Однако я действительно думаю, что Вы закончите тем, что пропустили в ряде ценных плагинов, таких как Гагатовый плагин и что Вы закончите тем, что делали целый набор работы, которую Вы не должны были делать со временем.

Более важный, чем знаток по сравнению с муравьем

  1. Это, Вы используете менеджер репозиториев для отслеживания артефакты программного обеспечения. Я предложил бы загрузить Nexus. Можно использовать Nexus, чтобы проксировать удаленные репозитории и предоставить место команде для развертывания внутренних артефактов.
  2. У Вас есть соответствующая модуляризация компонентов программного обеспечения. Один большой монолитный компонент редко масштабируется со временем. Поскольку Ваш проект разрабатывает, Вы захотите иметь понятие модулей и подмодулей. Знаток предоставляет себя этому подходу очень хорошо.
  3. Вы принимаете некоторые конвенции для своей сборки. Даже при использовании Муравья необходимо стремиться принять некоторую форму конвенции, которая согласовывается с другими проектами. Когда проект использует Знатока, это означает, что любой знакомый со Знатоком может взять сборку и начать работать с нею, не имея необходимость играть с конфигурацией только, чтобы выяснить, как получить вещь скомпилировать.
216
ответ дан hjpotter92 23 November 2019 в 20:15
поделиться

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

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

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

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

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

10
ответ дан 23 November 2019 в 20:15
поделиться

Maven - это фреймворк, Ant - это набор инструментов

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

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

XML Verbosity

Тобрайен - парень, который много знает о 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, конечно, не завершен. Нам все еще нужно определить цели, используемые для очистки, компиляции, тестирования и т. Д. Они определены в общем файле сборки, который импортируется всеми модулями в многомодульном проекте. Это подводит меня к вопросу о том, как все это должно быть явно написано в Ant, тогда как в Maven оно декларативно.

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

Сложность

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

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

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

В отличие от:

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

Знакомство

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

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

112
ответ дан 23 November 2019 в 20:15
поделиться
Другие вопросы по тегам:

Похожие вопросы: