it-swarm.com.de

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, was ist die Logik hinter einem Plugin und einem Abhängigkeit? 

77
Coral

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

Der Unterschied besteht jedoch darin, dass die meisten Arbeiten in maven mit Plugins erledigt werden. Die Abhängigkeit ist jedoch nur eine Jar-Datei, die während der Ausführung 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 dies nur das Plugin zum Klassenpfad hinzufügt und keine Kompilierung auslöst. Die Jar-Dateien, die dem Klassenpfad beim Kompilieren der Datei hinzugefügt werden sollen, werden als Abhängigkeit angegeben. 

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

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

Hoffe das beantwortet deine Frage!

151
r9891

Maven selbst kann als Küchenmaschine bezeichnet werden, die über viele verschiedene Einheiten verfügt, mit denen unterschiedliche Aufgaben ausgeführt werden können. Diese Einheiten werden Plugins genannt. Zum Kompilieren Ihres Projekts verwendet maven beispielsweise maven-compiler-plugin, um Tests auszuführen - maven-surefire-plugin und so weiter.

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

31
Andrew Logvinov

Plug-Ins werden zum Hinzufügen von Funktionalitäten zu Maven selbst verwendet (z. B. Hinzufügen von Eclipse-Unterstützung oder SpringBoot-Unterstützung zu Maven usw.). Abhängigkeiten werden von Ihrem Quellcode benötigt, um eine Maven-Phase zu passieren (beispielsweise compile oder test). Im Fall von JUnit, da der Testcode im Wesentlichen Teil Ihrer Codebasis ist und Sie JUnit-spezifische Befehle in Test Suites aufrufen und diese Befehle nicht von Java SDK bereitgestellt werden, muss JUnit zu dem Zeitpunkt vorhanden sein, zu dem Maven in der Testphase ist indem Sie JUnit als Abhängigkeit in Ihrer pom.xml-Datei angeben.

4
coffeMug

Wenn Sie wie ich aus einem Front-End-Hintergrund kommen und mit Grunt und Npm vertraut sind, stellen Sie sich Folgendes vor:

Zuerst würden Sie beispielsweise npm install grunt-contrib-copy --save-dev ausführen. Dies ist wie <dependency></dependency> von maven. 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/',
  },
}

Dies ist wie <plugin>/<plugin> von maven. Sie sagen dem Build-Tool, was mit dem von npm/<dependency></dependency> heruntergeladenen Code geschehen soll.

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

4
Kevin

Plugins und Abhängigkeiten sind sehr unterschiedlich und ergänzen sich. 

Was sind Plugins?

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

Dies ist das Herz von Maven.
Jede von Maven ausgeführte Aufgabe wird von Plugins ausgeführt .
Es gibt zwei Kategorien von Plugins: die build und die reporting plugins

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

Entsprechend dem in der Befehlszeile angegebenen Maven-Ziel (z. B. mvn clean, mvn clean package oder mvn site) wird ein bestimmter Lebenszyklus verwendet und ein bestimmter Satz von Plug-in-Zielen ausgeführt.
Es gibt drei integrierte Build-Lebenszyklen: default, clean und site. Der default-Lebenszyklus übernimmt die Projektbereitstellung, der clean-Lebenszyklus die Projektbereinigung, während der site-Lebenszyklus die Erstellung der Site-Dokumentation Ihres Projekts übernimmt. 

Ein Plugin-Ziel kann an eine bestimmte Phase eines bestimmten Lebenszyklus gebunden sein.
Zum Beispiel bindet maven-compiler-plugin standardmäßig das Ziel compile an die Lebenszyklusphase: compile.
Die meisten Maven-Plugins (sowohl Core-Plugins als auch Plugins von Drittanbietern) bevorzugen Konvention gegenüber Konfiguration. Daher haben diese ein Plugin-Ziel im Allgemeinen an eine bestimmte Phase gebunden, um die 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 unbedingt (siehe die scope unten). 

Die meisten Abhängigkeiten sind jar, aber es kann sich auch um andere Arten von Archiven handeln: Krieg, Ohr, Testglas, EJB-Client ... oder noch POM oder BOM.
In einer pom.xml können Abhängigkeiten an mehreren Stellen angegeben werden: <build><dependencies>, dependencies management oder noch in eine plugin-Deklaration! In der Tat müssen einige Plugins während ihrer Ausführung einige Abhängigkeiten im Klassenpfad haben. Das ist nicht üblich, aber das kann passieren.
Hier ist ein Beispiel aus der/- Dokumentation
das zeigt, dass plugin und dependency zusammenarbeiten können 

Beispielsweise verwendet das Maven Antrun Plugin Version 1.2 die Ant-Version 1.6.5, wenn Sie beim Ausführen dieses Plugins die neueste Ant-Version verwenden möchten, müssen Sie das <dependencies>-Element wie folgt 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 werden Abhängigkeiten in einem bestimmten Format referenziert:
groupId:artifactId:packaging:classifier:version.
Der Klassifizierer (der optional ist) und die Verpackung (standardmäßig JAR) werden nicht allgemein angegeben. Das übliche Format in der dependency-Deklaration lautet daher eher: groupId:artifactId:version.
Hier ist ein Beispiel für eine Abhängigkeit, die im <build><dependencies>-Teil deklariert ist: 

<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 Umfang (wieder Konvention über Konfiguration).
Der compile-Bereich bedeutet, dass die Abhängigkeit in allen Klassenpfaden eines Projekts verfügbar ist. 

Der Gültigkeitsbereich definiert, in welchen Klassenpfaden die Abhängigkeit hinzugefügt werden soll ..__ Benötigen wir sie zum Beispiel beim Kompilieren und zur Laufzeit oder nur zum Testen, Kompilieren und Ausführen? 

Zum Beispiel haben wir Hibernate zuvor als compile-Abhängigkeit definiert, wie wir sie überall brauchen: Quellkompilierung, Testkompilierung, Laufzeit usw.
Wir möchten jedoch nicht, dass Testbibliotheken in der Anwendung verpackt oder im Quellcode referenziert werden. Wir geben also den Bereich test 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>
4
davidxxx

Herzstück von Maven ist ein Plugin-Ausführungsframework - gemäß formaler und kompakter Standarddefinition. Um es klarer zu machen, die Befehle, die Sie wie maven-install/clean/compile/build etc verwenden, um Jars zu erstellen/auszuführen, die wir manchmal auch manuell ausführen. Also, die Dinge, die Sie ausführen (oder konfigurieren oder ausführen) möchten, setzen Sie im Wesentlichen in Abhängigkeitsmarkierungen von mavens pom und die Antwort darauf, wer diese Abhängigkeiten (die für die Einrichtung der Umgebung erforderlich sind) ausführt, die Plugins.

        javac (compiler) dependency.Java (dependency) 
1
Himanshu Ahuja