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



Я новичок в инструменте maven, я сделал проект с Spring и Hibernate, и они настроены в pom.xml как плагины, но JUnit помечается под зависимостью. Мой вопрос в том, какова логика одного как плагина и одного как зависимости ?

370   5  

5 ответов:

как плагины, так и зависимости являются файлами Jar.

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

например, вы используете компилятор-плагин для компиляции Java-файлов. Вы не можете использовать compiler-plugin в качестве зависимости, так как это только добавит плагин в путь к классам и не вызовет никакой компиляции. файл jar для добавления в путь к классу при компиляции файла, будет указан в качестве зависимости.

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

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

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

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

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

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

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

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

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

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

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

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

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

какие плагины ?

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

это сердце Maven .
любая задача, выполняемая Maven, выполняется плагинами.
Есть две категории плагинов:the build и reporting Плагины :

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

в соответствии с целью maven, указанной в командной строке (например mvn clean,mvn clean package или mvn site),определенный жизненный цикл будет использоваться и a конкретный набор плагинов цели будут выполнены.
Существует три встроенных жизненных цикла сборки:default,clean и site. Элемент default жизненный цикл обрабатывает развертывание проекта,clean lifecycle обрабатывает очистку проекта, в то время как 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 ... или еще пом или Бом.
В ПОМ.xml, зависимости могут быть указаны в нескольких местах:<build><dependencies> часть dependencies management часть или все еще в a plugin декларация ! Действительно, некоторые плагины могут иметь некоторые зависимости в classpath во время их выполнения. Это не часто, но это может случиться.
Вот пример из документация что показывает, что 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 scope означает, что зависимость доступна во всех путях к классам проекта.

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

например, мы ранее определяли 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>
    Ничего не найдено.

Добавить ответ:
Отменить.