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

Ich bin etwas spät dran mit dieser Frage, aber ich denke, sie ist eine klarere Antwort wert als die akzeptierte (die zwar richtig ist, aber nicht den eigentlich wichtigen Teil hervorhebt, den man selbst herausfinden muss).

In der übergeordneten POM ist der Hauptunterschied zwischen der <dependencies> y <dependencyManagement> ist dies:

• Artefakte, die in der <dependencies> Abschnitt wird IMMER als eine Abhängigkeit des/der untergeordneten Moduls/Module aufgenommen.

• Artefakte, die in der <dependencyManagement> werden nur dann in das untergeordnete Modul aufgenommen, wenn sie auch im Abschnitt <dependencies> Abschnitt des untergeordneten Moduls selbst. Warum ist das gut, fragen Sie? Weil Sie die Version und/oder den Gültigkeitsbereich im übergeordneten Modul angeben und sie weglassen können, wenn Sie die Abhängigkeiten im untergeordneten POM angeben. Auf diese Weise können Sie einheitliche Versionen für Abhängigkeiten für untergeordnete Module verwenden, ohne die Version in jedem untergeordneten Modul angeben zu müssen.

Answer 2

Verwaltung von Abhängigkeiten ermöglicht es, die Verwaltung von Abhängigkeitsversionen zu konsolidieren und zu zentralisieren, ohne Abhängigkeiten hinzuzufügen, die an alle Kinder vererbt werden. Dies ist besonders nützlich, wenn Sie eine Reihe von Projekten (d. h. mehr als eine), die einen gemeinsamen Elternteil erbt.

Ein weiterer äußerst wichtiger Anwendungsfall von dependencyManagement ist die Kontrolle der Versionen von Artefakten, die in transitiven Abhängigkeiten verwendet werden. Dies ist ohne ein Beispiel schwer zu erklären. Glücklicherweise wird dies in der Dokumentation veranschaulicht.

Answer 3

Eine Sache wird meiner Meinung nach immer noch nicht ausreichend hervorgehoben, und zwar ungewolltes Erbe .

Hier ein inkrementelles Beispiel:

Ich erkläre in meinem parent pom:

<dependencies>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>19.0</version>
        </dependency>
</dependencies>

Bumm! Ich habe es in meinem Child A , Child B y Child C Module:

• Vererbung von Implikaturen an Kinder
• Eine einzige Stelle zur Verwaltung
• Es ist nicht nötig, irgendetwas in den Kinderzimmern neu zu deklarieren.
• Ich kann immer noch nachsorgen und überschreiben version 18.0 in einem Child B wenn ich das möchte.

Aber was ist, wenn ich keine Guave in Child C und auch nicht in der Zukunft Child D y Child E Module?

Sie werden es trotzdem erben, und das ist unerwünscht! Das ist genau wie der Codegeruch von Java God Object, bei dem man einige nützliche Teile von einer Klasse erbt, aber auch eine Menge unerwünschter Dinge.

Dies ist der Ort, an dem <dependencyManagement> ins Spiel kommt. Wenn Sie dies zu Ihrem übergeordneten Pom hinzufügen, werden alle Ihre untergeordneten Module STOPP es zu sehen . Und so sind Sie gezwungen in jedes einzelne Modul zu gehen, das es benötigt, und es erneut zu deklarieren ( Child A y Child B (allerdings ohne die Version).

Und natürlich tun Sie es nicht für Child C und so bleibt Ihr Modul schlank.

Answer 4

El Dokumentation auf der Maven-Website ist furchtbar. Was dependencyManagement tut, ist einfach Ihre Abhängigkeitsdefinitionen (Version, Ausschlüsse, etc.) in das übergeordnete Pom zu verschieben, dann müssen Sie in den Child-Poms nur noch die groupId und artifactId angeben. Das ist alles (mit Ausnahme der Verkettung von übergeordneten Poms und dergleichen, aber das ist auch nicht wirklich kompliziert - dependencyManagement gewinnt über Abhängigkeiten auf der übergeordneten Ebene - aber wenn Sie eine Frage dazu oder zu Importen haben, ist die Maven-Dokumentation ein wenig besser).

Nachdem ich den ganzen 'a', 'b', 'c' Müll auf der Maven Seite gelesen habe und verwirrt war, habe ich das Beispiel umgeschrieben. Wenn Sie also 2 Projekte (proj1 und proj2) haben, die eine gemeinsame Abhängigkeit (betaShared) haben, können Sie diese Abhängigkeit nach oben in das übergeordnete Pom verschieben. Wenn Sie schon dabei sind, können Sie auch alle anderen Abhängigkeiten (alpha und charlie) nach oben verschieben, aber nur, wenn es für Ihr Projekt sinnvoll ist. Für die in den vorangegangenen Sätzen beschriebene Situation gibt es also eine Lösung mit dependencyManagement im übergeordneten Pom:

<!-- ParentProj pom -->
<project>
  <dependencyManagement>
    <dependencies>
      <dependency> <!-- not much benefit defining alpha here, as we only use in 1 child, so optional -->
        <groupId>alpha</groupId>
        <artifactId>alpha</artifactId>
        <version>1.0</version>
        <exclusions>
          <exclusion>
            <groupId>zebra</groupId>
            <artifactId>zebra</artifactId>
          </exclusion>
        </exclusions>
      </dependency>
      <dependency>
        <groupId>charlie</groupId> <!-- not much benefit defining charlie here, so optional -->
        <artifactId>charlie</artifactId>
        <version>1.0</version>
        <type>war</type>
        <scope>runtime</scope>
      </dependency>
      <dependency> <!-- defining betaShared here makes a lot of sense -->
        <groupId>betaShared</groupId>
        <artifactId>betaShared</artifactId>
        <version>1.0</version>
        <type>bar</type>
        <scope>runtime</scope>
      </dependency>
    </dependencies>
  </dependencyManagement>
</project>

<!-- Child Proj1 pom -->
<project>
  <dependencies>
    <dependency>
      <groupId>alpha</groupId>
      <artifactId>alpha</artifactId>  <!-- jar type IS DEFAULT, so no need to specify in child projects -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId>
      <artifactId>betaShared</artifactId>
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

<!-- Child Proj2 -->
<project>
  <dependencies>
    <dependency>
      <groupId>charlie</groupId>
      <artifactId>charlie</artifactId>
      <type>war</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
    <dependency>
      <groupId>betaShared</groupId> 
      <artifactId>betaShared</artifactId> 
      <type>bar</type> <!-- This is not a jar dependency, so we must specify type. -->
    </dependency>
  </dependencies>
</project>

Answer 5

Es ist, wie Sie sagten; dependencyManagement wird verwendet, um alle Abhängigkeitsinformationen in eine gemeinsame POM-Datei zu ziehen, was die Referenzen in der Child-POM-Datei vereinfacht.

Dies ist nützlich, wenn Sie mehrere Attribute haben, die Sie nicht in mehreren untergeordneten Projekten erneut eingeben möchten.

Endlich, dependencyManagement kann verwendet werden, um eine Standardversion eines Artefakts zu definieren, die über mehrere Projekte hinweg verwendet werden kann.