Was ist der Unterschied in maven zwischen Abhängigkeits- und Plugin-Tags in pom xml?

Ich bin neu im Maven-Tool. Ich habe ein Projekt mit Spring und Hibernate erstellt und sie sind in pom.xml als Plugins konfiguriert, aber JUnit ist unter Abhängigkeit markiert. Meine Frage ist, welche Logik steckt hinter einem als Plugin und einem als Abhängigkeit?

Sowohl Plugins als auch Abhängigkeiten sind Jar-Dateien.

Der Unterschied zwischen ihnen besteht jedoch darin, dass der größte Teil der Arbeit in Maven mit Plugins erledigt wird. Die Abhängigkeit ist nur eine Jar-Datei, die beim Ausführen der Aufgaben zum Klassenpfad hinzugefügt wird.

Beispielsweise verwenden Sie ein Compiler-Plugin, um die Java-Dateien zu kompilieren. Sie können das Compiler-Plugin nicht als Abhängigkeit verwenden, da dadurch nur das Plugin zum Klassenpfad hinzugefügt wird und keine Kompilierung ausgelöst wird. Die Jar-Dateien, die beim Kompilieren der Datei zum Klassenpfad hinzugefügt werden sollen, werden als Abhängigkeit angegeben.

Gleiches gilt für Ihr Szenario. Sie müssen das Spring-Plugin verwenden, um einige ausführbare Spring-Dateien auszuführen. [Ich bin nicht sicher, wofür Spring-Plugins verwendet werden. Ich rate hier nur]. Sie benötigen jedoch Abhängigkeiten, um diese ausführbaren Dateien auszuführen. Und Junit ist unter Abhängigkeit markiert, da es vom todsicheren Plugin zur Ausführung von Komponententests verwendet wird.

Wir können also sagen, dass das Plugin eine Jar-Datei ist, die die Aufgabe ausführt, und die Abhängigkeit eine Jar-Datei ist, die die Klassendateien zur Ausführung der Aufgabe bereitstellt.

Hoffe das beantwortet deine Frage!

Maven selbst kann als Küchenmaschine mit vielen verschiedenen Einheiten beschrieben werden, mit denen verschiedene Aufgaben ausgeführt werden können. Diese Einheiten werden Plugins genannt. Zum Beispiel, um Ihre Projekt-Maven-Kompilierungen zu kompilieren maven-compiler-plugin, Tests auszuführen - maven-surefire-pluginund so weiter.

Die Abhängigkeit in Bezug auf Maven ist ein Paket von Klassen, von denen Ihr Projekt abhängt. Dies kann JAR, Krieg usw. sein. Wenn Sie beispielsweise einen JUnit-Test schreiben möchten, müssen Sie JUnit-Annotationen und -Klassen verwenden. Daher müssen Sie erklären, dass Ihr Projekt von JUnit abhängt.

Plugins und Abhängigkeiten sind sehr unterschiedliche Dinge und diese ergänzen sich.

Was sind Plugins?

Plugins führen Aufgaben für einen Maven-Build aus. Diese sind nicht in der Anwendung enthalten.

Dies sind die Herzen von Maven.
Jede von Maven ausgeführte Aufgabe wird von Plugins ausgeführt .
Es gibt zwei Kategorien von Plugins: das buildund das reportingPlugin :

• Build-Plugins werden während des Builds ausgeführt und sollten im <build/>Element aus dem POM konfiguriert werden .
• Berichts-Plugins werden während der Site-Generierung ausgeführt und sollten im <reporting/Element> des POM konfiguriert werden .

Nach dem Maven Ziel in der Befehlszeile angegeben (zum Beispiel mvn clean, mvn clean packageoder mvn site), eine spezifische lifecyle verwendet werden und eine bestimmte Gruppe von Plugins Zielen ausgeführt.
Es gibt drei Einbau-Build - Lifecycles: default, cleanund site. Der defaultLebenszyklus übernimmt Ihre Projektbereitstellung, der cleanLebenszyklus die Projektbereinigung und der siteLebenszyklus die Erstellung der Standortdokumentation Ihres Projekts.

Ein Plugin-Ziel kann an eine bestimmte Phase eines bestimmten Lebenszyklus gebunden sein.
Zum Beispiel maven-compiler-pluginbindet das compileZiel standardmäßig an die Lebenszyklusphase : compile.
Die meisten Maven-Plugins (sowohl Core-Plugins als auch Plugins von Drittanbietern) bevorzugen Konventionen gegenüber Konfigurationen. Daher haben diese ein Plugin-Ziel im Allgemeinen an eine bestimmte Phase gebunden, um ihre Verwendung zu vereinfachen.

Das ist ordentlicher und weniger fehleranfällig:

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

als :

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

Welche Abhängigkeiten gibt es?

Abhängigkeiten sind Maven-Artefakte / -Komponenten, die während des Maven-Builds im Klassenpfad erforderlich sind.
Diese können in der Anwendung enthalten sein, müssen aber nicht (siehe scopeunten).

Die meisten Abhängigkeiten sind jar, aber dies können auch andere Arten von Archiven sein: war, ear, test-jar, ejb-client ... oder immer noch POM oder BOM.
In einer pom.xml können Abhängigkeiten an mehreren Stellen angegeben werden: am <build><dependencies>Teil, am dependencies managementTeil oder noch in einer pluginDeklaration ! In der Tat müssen einige Plugins während ihrer Ausführung möglicherweise einige Abhängigkeiten im Klassenpfad aufweisen. Das ist nicht üblich, aber das kann passieren.
Hier ist ein Beispiel aus der Dokumentation , das dies zeigt pluginund dependencymöglicherweise zusammenarbeitet:

Das Maven Antrun Plugin Version 1.2 verwendet beispielsweise Ant Version 1.6.5. Wenn Sie beim Ausführen dieses Plugins die neueste Ant-Version verwenden möchten, müssen Sie ein <dependencies>Element wie das folgende hinzufügen :

<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 wird auf Abhängigkeiten in einem bestimmten Format verwiesen :
groupId:artifactId:packaging:classifier:version.
Der Klassifizierer (der optional ist) und die Verpackung ( JARstandardmäßig) werden nicht allgemein angegeben. Das übliche Format in der dependencyErklärung lautet also eher : groupId:artifactId:version.
Hier ist ein Beispiel für die im <build><dependencies>Teil deklarierte Abhängigkeit :

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

Im Gegensatz zu einem Plugin hat eine Abhängigkeit einen Gültigkeitsbereich.
Der Standardbereich ist compile. Dies ist der am häufigsten benötigte Bereich (Konvention über Konfiguration erneut).
Der compileBereich bedeutet, dass die Abhängigkeit in allen Klassenpfaden eines Projekts verfügbar ist.

Der Bereich definiert, in welchen Klassenpfaden die Abhängigkeit hinzugefügt werden soll. Benötigen wir es zum Beispiel zur Kompilierung und Laufzeit oder nur zum Kompilieren und Ausführen von Tests?

Zum Beispiel haben wir Hibernate zuvor als compileAbhängigkeit definiert, wie wir sie überall brauchen: Quellkompilierung, Testkompilierung, Laufzeit usw.
Wir möchten jedoch nicht, dass Testbibliotheken in der Anwendung gepackt oder im Quellcode referenziert werden . Also geben wir den testUmfang für sie an:

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

Wenn Sie aus einem Front-End-Hintergrund wie mir kommen und mit Grunt und npm vertraut sind, stellen Sie sich das so vor:

Zuerst würden Sie sagen, sagen npm install grunt-contrib-copy --save-dev. Das ist wie bei Maven <dependency></dependency>. Es lädt die Dateien herunter, die zum Ausführen einer Build-Aufgabe erforderlich sind.

Dann würden Sie die Aufgabe in Gruntfile.js konfigurieren

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

Das ist wie bei Maven <plugin>/<plugin>. Sie teilen dem Build-Tool mit, was mit dem von npm / heruntergeladenen Code zu tun ist <dependency></dependency>.

Natürlich ist dies keine exakte Analogie, aber nah genug, um Ihren Kopf darum zu wickeln.

Plug-Ins werden zum Hinzufügen von Funktionen zu sich Mavenselbst verwendet (z. B. Hinzufügen von eclipseSupport oder SpringBootSupport zu Mavenusw.). Abhängigkeiten werden von Ihrem Quellcode benötigt, um eine Maven-Phase ( compileoder testzum Beispiel) zu bestehen. Im Falle der JUnitseit der Testcode ist im Grunde ein Teil Ihrer Code - Basis und rufen Sie JUnitbestimmte Befehle in Testsuiten und diese Befehle werden nicht von einer dritten Java SDKdaher JUnitmuss zum Zeitpunkt vorhanden sein , Mavenist in der Testphase , und dies wird durch die Erwähnung behandelt JUnitals Abhängigkeit in Ihrer pom.xmlDatei.

Maven ist das Herzstück eines Plugin-Ausführungsframeworks - gemäß formaler und standardmäßiger kompakter Definition. Um es klarer zu machen, verwenden Sie die Befehle maven-install/clean/compile/build etczum Erstellen / Ausführen von Jars, die wir manchmal auch manuell ausführen. Die Dinge, die Sie ausführen (oder konfigurieren oder ausführen) möchten, setzen Sie im Grunde genommen in das Abhängigkeitstag von mavens pom und die Antwort, wer diese Abhängigkeiten ausführen wird (für die Einrichtung der Umgebung erforderlich), sind die Plugins.

        javac (compiler) dependency.java (dependency) 

Einzeilige Antwort - Grundverständnis

Das Plugin ist ein Tool, das Sie bei der Ausführung Ihres Maven-Builds verwenden

Abhängigkeit bedeutet jede Art von Bibliothek, die Sie in Ihrem Code verwenden

Ein Plugin ist eine Erweiterung von Maven, die zur Herstellung Ihres Artefakts verwendet wird (Maven-Jar-Plugin zum Beispiel wird verwendet, um aus Ihren kompilierten Klassen und Ressourcen ein Jar zu erstellen).

Eine Abhängigkeit ist eine Bibliothek, die von der von Ihnen erstellten Anwendung zum Kompilieren und / oder Testen und / oder zur Laufzeit benötigt wird.