В чем разница между maven между зависимостью и тегами плагина в pom xml?

Ответ 1

Оба плагина и зависимые файлы Jar.

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

Например, вы используете компилятор-плагин для компиляции java файлов. Вы не можете использовать компилятор-плагин как зависимость, так как это добавит плагин в путь к классам и не будет запускать какую-либо компиляцию. Файлы Jar, которые будут добавлены в путь к классам при компиляции файла, будут указаны как зависимость.

То же самое происходит с вашим сценарием. Вы должны использовать spring -plugin для выполнения некоторых исполняемых файлов spring [Я не уверен, для чего используются spring -plugins. Я просто угадываю здесь]. Но для выполнения этих исполняемых файлов нужны зависимости. И Junit помечен под зависимостью, так как он используется плагином surefire для выполнения модульных тестов.

Итак, мы можем сказать, что плагин - это Jar файл, который выполняет задачу, а зависимость - это Jar, который предоставляет файлы классов для выполнения задачи.

Надеюсь, что ответит на ваш вопрос!

Ответ 2

Сам Maven может быть описан как пищевой процессор, который имеет много разных единиц, которые могут использоваться для выполнения различных задач. Эти единицы называются плагинами. Например, для компиляции вашего проекта maven использует maven-compiler-plugin, для запуска тестов - maven-surefire-plugin и т.д.

Зависимость в терминах maven - это упакованная часть классов, от которой зависит ваш проект. Это может быть jar, war и т.д. Например, если вы хотите написать JUnit test, вам нужно будет использовать аннотации и классы JUnit, поэтому вы должны заявить, что ваш проект зависит от JUnit.

Ответ 3

Плагины используются для добавления функций к Maven (например, добавление поддержки eclipse или SpringBoot поддержка Maven и т.д.). Зависимости необходимы в исходном коде для прохождения любой фазы Maven (например, compile или test). В случае JUnit, поскольку тестовый код в основном является частью вашей базы кода, и вы вызываете JUnit конкретные команды внутри наборов тестов, и эти команды не предоставляются Java SDK, поэтому JUnit должен присутствовать в момент Maven > находится в тестовой фазе, и это связано с упоминанием JUnit как зависимости в вашем файле pom.xml.

Ответ 4

Если вы работаете с интерфейсом, похожим на меня, и знакомы с Grunt и npm, подумайте об этом следующим образом:

Сначала вы запустили, скажем, npm install grunt-contrib-copy --save-dev. Это похоже на maven <dependency></dependency>. Он загружает файлы, необходимые для выполнения задачи сборки.

Затем вы должны настроить задачу в Gruntfile.js

copy: {
  main: {
    src: 'src/*',
    dest: 'dest/',
  },
}

Это похоже на maven <plugin>/<plugin>. Вы сообщаете инструменту сборки, что делать с кодом, загруженным npm/<dependency></dependency>.

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

Ответ 5

Плагины и зависимости очень разные вещи, и они дополняют друг друга.

Какие плагины есть?

Плагины выполняют задачи для сборки Maven. Они не упакованы в приложении.

Это сердце Maven.
Любое задание, выполняемое Maven, выполняется плагинами.
Существует две категории плагинов: build и плагины reporting:

• Плагины сборки будут выполняться во время сборки и должны быть настроены в элементе <build/> из POM.
• Плагины отчетности будут выполняться во время генерации сайта, и они должны быть настроены в элементе <reporting/ > из POM.

В соответствии с целью maven, указанной в командной строке (например, mvn clean, mvn clean package или mvn site), будет использоваться определенный жизненный цикл и будет выполняться определенный набор целей плагинов.
Существует три встроенных жизненных цикла сборки: по default, clean и site. Жизненный цикл по default обрабатывает развертывание вашего проекта, clean жизненный цикл обрабатывает очистку проекта, в то время как жизненный цикл site управляет созданием документации сайта вашего проекта.

Цель плагина может быть привязана к определенной фазе определенного жизненного цикла.
Например, maven-compiler-plugin по умолчанию связывает цель compile с фазой жизненного цикла: compile.
Большинство плагинов maven (как плагинов ядра, так и плагинов сторонних производителей) предпочитают соглашение о конфигурации Таким образом, они обычно связывают цель плагина с определенной фазой, чтобы упростить их использование.

Это аккуратнее и менее подвержено ошибкам:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
</plugin>

чем:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
  <executions>
    <execution>
        <phase>compile</phase>
        <goals>
            <goal>compile</goal>
        </goals>
    </execution>
  </executions>
</plugin>

Какие есть зависимости?

Зависимости - это артефакты/компоненты Maven, необходимые в пути к классам во время сборки Maven.
Они могут быть упакованы в приложение, но не обязательно (см. scope ниже).

Большинство зависимостей - это jar, но это могут быть и другие виды архивов: war, ear, test-jar, ejb-client... или все еще POM или BOM.
В файле pom.xml зависимости могут быть указаны в нескольких местах: в части <build><dependencies>, в части dependencies management или в объявлении plugin ! Действительно, некоторые плагины могут нуждаться в некоторых зависимостях в пути к классам во время их выполнения. Это не часто, но это может случиться.
Вот пример из документации, которая показывает, что plugin и dependency могут работать вместе:

Например, плагин Maven Antrun версии 1.2 использует Ant версии 1.6.5. Если вы хотите использовать самую последнюю версию Ant при запуске этого плагина, вам нужно добавить элемент <dependencies> как показано ниже:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.2</version>
        ...
        <dependencies>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant</artifactId>
            <version>1.7.1</version>
          </dependency>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant-launcher</artifactId>
            <version>1.7.1</version>
          </dependency>
         </dependencies>
      </plugin>
    </plugins>
  </build>
  ...
</project>

В Maven на зависимости ссылаются в определенном формате:
groupId:artifactId:packaging:classifier:version.
Классификатор (это необязательно) и упаковка (JAR по умолчанию) обычно не указываются. Таким образом, общий формат в объявлении dependency скорее: groupId:artifactId:version.
Вот пример зависимости, объявленной в части <build><dependencies>:

<build>
   <dependencies>
      <dependency>
         <groupId>org.hibernate</groupId>
         <artifactId>hibernate-core</artifactId>
         <version>5.2.14.Final</version>
      </dependency>
   <dependencies>
</build>

В отличие от плагина, у зависимости есть область.
Область действия по умолчанию - compile. Это наиболее часто используемая область (снова соглашение о конфигурации).
Область compile означает, что зависимость доступна во всех классовых путях проекта.

Область действия определяет, в какие пути к классам должна быть добавлена зависимость. Например, нужно ли это во время компиляции и выполнения или только для компиляции и выполнения тестов?

Например, мы ранее определили Hibernate как зависимость compile как она нам нужна везде: компиляция исходного кода, тестовая компиляция, время выполнения и так далее для....
Но мы не хотим, чтобы тестовые библиотеки могли быть упакованы в приложении или иметь ссылки в исходном коде. Поэтому мы указываем область test для них:

<build>
   <dependencies>
     <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.1.0</version>
        <scope>test</scope>
     </dependency>
   <dependencies>
</build>

Ответ 6

В основе Maven лежит структура исполнения плагинов - согласно формальному и стандартному компактному определению. Чтобы сделать это более понятным, команды, которые вы используете, такие как maven-install/clean/compile/build etc Для создания/выполнения jar файлов, которые мы иногда также запускаем вручную. Итак, те вещи, которые вы хотите запустить (или настроить, или выполнить), вы в основном помещаете их в тег зависимостей mavens pom и в ответ на вопрос, кто будет запускать эти зависимости (необходимые для настройки среды), как плагины.

        javac (compiler) dependency.java (dependency)