Unterschiede zwischen dependencyManagement und Abhängigkeiten in Maven

Question

Was ist der Unterschied zwischen dependencyManagement y dependencies ? Ich habe die Dokumente auf der Apache Maven Website gesehen. Es scheint, dass eine Abhängigkeit, die unter dem dependencyManagement kann in seinen untergeordneten Modulen ohne Angabe der Version verwendet werden.

Zum Beispiel:

Ein übergeordnetes Projekt (Pro-par) definiert eine Abhängigkeit unter dem dependencyManagement :

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8</version>
    </dependency>
 </dependencies>
</dependencyManagement>

Dann kann ich in dem Kind von Pro-par das Junit verwenden:

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
    </dependency>
 </dependencies>

Ich frage mich jedoch, ob es notwendig ist, junit in der übergeordneten pom zu definieren? Warum wird es nicht direkt im benötigten Modul definiert?

Answer 1

Der Unterschied zwischen den beiden wird am besten in der scheinbar notwendigen und ausreichenden Definition des dependencyManagement-Elements deutlich, die in den Maven-Webseiten-Dokumenten zu finden ist:

dependencyManagement

"Standard-Abhängigkeitsinformationen für Projekte, die von diesem Projekt erben. Die Abhängigkeiten in diesem Abschnitt werden nicht sofort aufgelöst. Wenn stattdessen ein von diesem abgeleitetes POM eine Abhängigkeit deklariert, die durch eine passende groupId und artifactId beschrieben wird, werden die Version und andere Werte aus diesem Abschnitt für diese Abhängigkeit verwendet, wenn sie nicht bereits angegeben wurden." [ https://maven.apache.org/ref/3.6.1/maven-model/maven.html ]

Sie sollte zusammen mit einigen weiteren Informationen auf einer anderen Seite gelesen werden:

" der minimale Satz an Informationen für den Abgleich einer Abhängigkeitsreferenz mit einem dependencyManagement-Abschnitt ist eigentlich {groupId, artifactId, type, classifier}. In vielen Fällen beziehen sich diese Abhängigkeiten auf jar-Artefakte ohne Klassifikator. Dies erlaubt es uns, den Identitätssatz auf {groupId, artifactId} abzukürzen, da der Standard für das type-Feld jar ist und der Standard-Klassifikator null ist." [ https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html ]

Somit sind alle Subelemente (Geltungsbereich, Ausschlüsse usw.) eines Abhängigkeitselements - außer groupId, artifactId, type, classifier, nicht nur version - für Lockdown/Default an dem Punkt verfügbar (und werden somit von dort an vererbt), an dem Sie die Abhängigkeit innerhalb eines dependencyElements angeben. Wenn Sie eine Abhängigkeit mit den Unterelementen type und classifier (siehe die erstgenannte Webseite, um alle Unterelemente zu überprüfen) als not jar bzw. not null angegeben haben, benötigen Sie {groupId, artifactId, classifier, type}, um diese Abhängigkeit an einem beliebigen Punkt in einer Vererbung zu referenzieren (aufzulösen), die vom dependencyManagement-Element ausgeht. Andernfalls würde {groupId, artifactId} ausreichen, wenn Sie nicht beabsichtigen, die Standardwerte für classifier und type (jar bzw. null) außer Kraft zu setzen. Standard ist also ein gutes Schlüsselwort in dieser Definition; alle Unterelemente (außer groupId, artifactId, classifier und type natürlich), denen an dem Punkt, an dem Sie auf eine Abhängigkeit verweisen, explizit Werte zugewiesen werden, setzen die Standardwerte im dependencyManagement-Element außer Kraft.

So wird jedes Abhängigkeitselement außerhalb von dependencyManagement, ob als Verweis auf ein dependencyManagement-Element oder als eigenständiges Element, sofort aufgelöst (d.h. im lokalen Repository installiert und für Klassenpfade verfügbar).

Answer 2

In Eclipse gibt es eine weitere Funktion in der dependencyManagement . Wenn dependencies ohne diese Option verwendet wird, werden die nicht gefundenen Abhängigkeiten in der pom-Datei vermerkt. Wenn dependencyManagement verwendet wird, bleiben die nicht aufgelösten Abhängigkeiten in der pom-Datei unbemerkt und Fehler erscheinen nur in den Java-Dateien. (Importe und so...)

Answer 3

Ich empfehle nicht die Verwendung von dependencyManagement .

Der einzige Vorteil ist, dass Sie die Version im übergeordneten Pom definieren können und sie im untergeordneten Pom nicht erneut definieren müssen. Aber wenn Sie eine Reihe von Projekten haben (insbesondere Mikro-Service-Projekte). Verwendung von dependencyManagement hat keine Vorteile.

Verschiedene Projekte können unterschiedliche Abhängigkeiten benötigen. Warum sollte man sie von demselben übergeordneten Pom erben. Halten Sie es so einfach wie möglich . Wenn ein Projekt eine Abhängigkeit benötigt, dann fügen Sie diese der pom-Datei hinzu. Verwirren Sie die Entwickler nicht.

Answer 4

Wenn Sie ohnehin einen Eltern-Pom haben, dann sollten Sie meiner Meinung nach <dependencyManagement> nur zur Kontrolle der Version (und vielleicht des Umfangs) ist eine Platzverschwendung und verwirrt junge Entwickler.

Wahrscheinlich haben Sie ohnehin Eigenschaften für Versionen in einer Art Parent-Pom-Datei. Warum nicht einfach diese Eigenschaften in den Child-Pom-Dateien verwenden? Auf diese Weise können Sie immer noch eine Version in der Eigenschaft (in der übergeordneten Pom-Datei) für alle untergeordneten Projekte auf einmal aktualisieren. Das hat den gleichen Effekt wie <dependencyManagement> gerade ohne <dependencyManagement> .

Meiner Meinung nach, <dependencyManagement> sollte für die "echte" Verwaltung von Abhängigkeiten, wie Ausschlüsse und Ähnliches, verwendet werden.

Answer 5

Sie wurde erklärt von aquí leicht zu verstehen sein. Der Unterschied zwischen dependencyManagement & dependencies sind Deklaration und tatsächliche Addition