pom xml의 종속성과 플러그인 태그 간의 Maven의 차이점은 무엇입니까?

pom xml의 종속성과 플러그인 태그 간의 Maven의 차이점은 무엇입니까?

---

나는 maven 도구를 처음 접했고 Spring과 Hibernate로 프로젝트를 만들었고 pom.xml에서 플러그인으로 구성되었지만 JUnit은 종속성 아래에 태그가 지정되었습니다. 내 질문은 플러그인과 종속성의 논리는 무엇입니까?

---

플러그인과 종속성은 모두 Jar 파일입니다.

하지만 차이점은 maven의 대부분의 작업은 플러그인을 사용하여 수행된다는 것입니다. 반면 종속성은 작업을 실행하는 동안 클래스 경로에 추가되는 Jar 파일입니다.

예를 들어, 컴파일러 플러그인을 사용하여 Java 파일을 컴파일합니다. 컴파일러 플러그인은 클래스 경로에 플러그인 만 추가하고 컴파일을 트리거하지 않기 때문에 종속성으로 사용할 수 없습니다. 파일을 컴파일하는 동안 클래스 경로에 추가 될 Jar 파일은 종속성으로 지정됩니다.

시나리오도 마찬가지입니다. 일부 스프링 실행 파일을 실행하려면 spring-plugin을 사용해야합니다. [spring-plugins가 어떤 용도로 사용되는지 잘 모르겠습니다. 나는 단지 여기에서 추측하고있다]. 그러나 이러한 실행 파일을 실행하려면 종속성이 필요합니다. 그리고 Junit은 단위 테스트를 실행하기 위해 surefire-plugin에서 사용되기 때문에 종속성 아래에 태그가 지정됩니다.

따라서 plugin은 태스크를 실행하는 Jar 파일이고, Dependency는 태스크를 실행하기위한 클래스 파일을 제공하는 Jar라고 할 수 있습니다.

귀하의 질문에 대한 답변이 되었기를 바랍니다.

---

Maven 자체는 다양한 작업을 수행하는 데 사용할 수있는 다양한 단위를 가진 푸드 프로세서로 설명 할 수 있습니다. 이러한 단위를 플러그인이라고합니다. 예를 들어, 프로젝트를 컴파일하려면 maven을 사용 maven-compiler-plugin하여 테스트를 실행합니다 maven-surefire-plugin.

Maven 측면에서 종속성은 프로젝트가 의존하는 패키지 된 클래스 조각입니다. jar, war 등이 될 수 있습니다. 예를 들어 JUnit 테스트를 작성하려면 JUnit 주석과 클래스를 사용해야하므로 프로젝트가 JUnit에 종속됨을 선언해야합니다.

---

플러그인과 종속성은 매우 다르며 상호 보완 적입니다.

플러그인은 무엇입니까?

플러그인은 Maven 빌드를위한 작업을 수행합니다. 이들은 응용 프로그램에 패키지되어 있지 않습니다.

이것들이 Maven의 핵심입니다.
Maven이 실행하는 모든 작업은 플러그인에 의해 수행됩니다 .
두 개의 플러그인의 범주가 있습니다 와 플러그인 :buildreporting

• 빌드 플러그인은 빌드 중에 실행 <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아래 참조).

The most of dependencies are jar but these may also be other kinds of archives : war, ear, test-jar, ejb-client ... or still POM or BOM.
In a pom.xml, dependencies may be specified at multiple places : the <build><dependencies> part , the dependencies management part or still in a plugin declaration ! Indeed some plugins may need to have some dependencies in the classpath during their execution. That is not common but that may happen.
Here is an example from the documentation that shows that plugin and dependency may work together :

For instance, the Maven Antrun Plugin version 1.2 uses Ant version 1.6.5, if you want to use the latest Ant version when running this plugin, you need to add <dependencies> element like the following:

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

In Maven, dependencies are referenced in a specific format :
groupId:artifactId:packaging:classifier:version.
The classifier (that is optional) and the packaging (JAR by default) are not commonly specified. So the common format in the dependency declaration is rather : groupId:artifactId:version.
Here is an example of dependency declared in the <build><dependencies> part :

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

Contrary to a plugin, a dependency has a scope.
The default scope is compile. That is the most commonly needed scope (convention over configuration again).
The compile scope means that the dependency is available in all classpaths of a project.

The scope defines in which classpaths the dependency should be added. For example do we need it at compile and runtime, or only for tests compilation and execution ?

For example we previously defined Hibernate as a compile dependency as we need it everywhere : source compilation, test compilation, runtime and so for....
But we don't want that testing libraries may be packaged in the application or referenced in the source code. So we specify the test scope for them :

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

---

If you're coming from a front-end background like me, and are familiar with Grunt and npm, think of it like this:

First you would run, say, npm install grunt-contrib-copy --save-dev. This is like maven's <dependency></dependency>. It downloads the files needed to execute a build task.

Then you would configure the task in Gruntfile.js

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

This is like maven's <plugin>/<plugin>. You are telling the build tool what to do with the code downloaded by npm/<dependency></dependency>.

Of course this is not an exact analogy, but close enough to help wrap your head around it.

---

Plug-ins are used for adding functionalities to Maven itself (like adding eclipse support or SpringBoot support to Maven etc.). Dependencies are needed by your source code to pass any Maven phase (compile or test for example). In case of JUnit since the test code is basically part of your code base and you call JUnit specific commands inside test suites and those commands are not provided by Java SDK therefore JUnit must be present at the time Maven is in the test phase and this is handled by mentioning JUnit as a dependency in your pom.xml file.

---

Maven at its heart is a plugin execution framework -- as per formal and standard compact definition. To make it more clear, the commands you use like maven-install/clean/compile/build etc for creating/executing jars, which we sometimes manually run too. So, the things which you want to run (or configure or execute) you basically put them in dependency tag of mavens pom and the answer so as to who will run these dependencies (required for environment setup) be the plugins.

        javac (compiler) dependency.java (dependency) 

참고URL : https://stackoverflow.com/questions/11881663/what-is-the-difference-in-maven-between-dependency-and-plugin-tags-in-pom-xml