Różnice między zarządzaniem zależnościami a zależnościami w Maven

Jestem modnie spóźniony na to pytanie, ale myślę, że warto odpowiedzieć jaśniej niż przyjęte (co jest poprawne, ale nie podkreśla rzeczywistej ważnej części, którą trzeba wydedukować).

W macierzystym POM, główna różnica między <dependencies> oraz <dependencyManagement> jest to:

Artefakty określone w <dependencies> sekcja zawsze będzie dołączona jako zależność modułów potomnych.

Artefakty określone w <dependencyManagement> sekcji, będą zawarte w module potomnym tylko wtedy, gdy zostały one również określone w <dependencies> sekcja samego modułu dziecka. Dlaczego dobrze pytasz? ponieważ określasz wersję i / lub zakres w rodzicu i możesz je pominąć, gdy określasz zależności w podrzędnym POM. Może to pomóc w używaniu ujednoliconych wersji dla Zależności dla modułów potomnych, bez określania wersji w każdym module potomnym.

Jest tak jak powiedziałeś; dependencyManagement jest używany do pobierania wszystkich informacji o zależnościach do wspólnego pliku POM, upraszczając odniesienia w pliku POM potomnym.

Staje się przydatna, gdy masz wiele atrybutów, których nie chcesz wpisywać ponownie w ramach wielu projektów potomnych.

Wreszcie, dependencyManagement może być użyty do zdefiniowania standardowej wersji artefaktu do wykorzystania w wielu projektach.

Dokumentacja na stronie Mavena jest okropna. To, co robi dependencyManagement, to po prostu przeniesienie definicji zależności (wersji, wykluczeń itp.) do pom rodzica, a następnie w pomach potomnych wystarczy umieścić groupId i artifactId. To wszystko (z wyjątkiem parent pom chaining i tym podobne, ale to też nie jest zbyt skomplikowane - dependencyManagement wygrywa z zależnościami na poziomie rodzica - ale jeśli masz pytanie o to lub import, Maven dokumentacja jest trochę lepsza).

Po przeczytaniu wszystkich śmieci "a", "b", " c " na stronie Maven i zmieszaniu się, napisałem ponownie ich przykład. Więc jeśli masz 2 projekty (proj1 i proj2), które mają wspólną zależność (betaShared), możesz przenieść tę zależność do macierzystego pom. W tym czasie możesz również przenieść inne zależności (alpha i charlie), ale tylko wtedy, gdy ma to sens dla Twojego projektu. Tak więc dla sytuacji nakreślonej w poprzednich zdaniach, oto rozwiązanie z dependencyManagement w macierzystym 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>

Jest jeszcze jedna rzecz, która nie jest wystarczająco podkreślona, moim zdaniem, a jest nią niechciane dziedzictwo.

Oto przykład Przyrostowy:

Deklaruję w moim parent pom:

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

Boom! Mam to w moim Child A, Child B i Child C moduły:

• Implicilty dziedziczone przez dzieci poms
• jedno miejsce do zarządzania
• nie ma potrzeby przepisywania czegokolwiek w dziecięcych pomach
• I can still redelcare and override to version 18.0 in a Child B jeśli chcę.

Ale co, jeśli skończę nie potrzebując guava w Child C, ani w przyszłości Child D i Child E modułów?

I tak ją odziedziczą, a to jest niepożądane! To jest tak jak zapach kodu obiektowego Java God, w którym dziedziczysz przydatne bity z klasy, a także mnóstwo niechcianych rzeczy.

To tutaj <dependencyManagement> wchodzi w grę. Gdy dodasz to do pom rodzica, wszystkie moduły potomne przestaną go widzieć. I tak ty są zmuszone , aby przejść do każdego modułu, który go potrzebuje i zadeklarować go ponownie (Child A i Child B, jednak bez wersji).

I, oczywiście, nie robisz tego dla Child C, a zatem Twój moduł pozostaje chuda.

Jeśli zależność została zdefiniowana w elemencie dependencyManagement pom najwyższego poziomu, projekt potomny nie musiał jawnie wypisywać wersji zależności. jeśli projekt potomny zdefiniuje wersję, nadpisuje wersję wymienioną na najwyższym poziomie Sekcja zarządzania zależnościami POM. Oznacza to, że wersja dependencyManagement jest tylko używany, gdy dziecko nie deklaruje bezpośrednio wersji.

Istnieje kilka odpowiedzi opisujących różnice między tagami <depedencies> i <dependencyManagement> z maven.

Jednak kilka punktów omówionych poniżej w zwięzły sposób:

1. <dependencyManagement> pozwala skonsolidować wszystkie zależności (używane na poziomie pom dziecka) używane w różnych modułach -- klarowność, centralne zarządzanie wersjami zależności
2. <dependencyManagement> pozwala na łatwe uaktualnianie / obniżanie zależności w zależności od potrzeb, w innym scenariuszu należy to wykonać u każdego dziecka poziom pom -- spójność
3. zależności podane w znaczniku <dependencies> są zawsze importowane, podczas gdy zależności podane w znaczniku <dependencyManagement> w macierzystym pom będą importowane tylko wtedy, gdy potomny pom ma odpowiedni wpis w znaczniku <dependencies>.

W macierzystym POM, główna różnica między <dependencies> i <dependencyManagement> jest następująca:

Artefakty określone w sekcji <dependencies> będą zawsze uwzględniane jako zależność modułów potomnych.

Artefakty określone w sekcji zostaną włączone do modułu potomnego tylko wtedy, gdy zostały również określone w sekcji samego modułu potomnego. Dlaczego dobrze pytasz? ponieważ podajesz wersję i / lub zakres w rodzicu i możesz je pominąć, gdy podajesz zależności w pom. dziecięcym. Może to pomóc w używaniu ujednoliconych wersji dla Zależności dla modułów potomnych, bez określania wersji w każdym module potomnym.

W Eclipse jest jeszcze jedna cecha w dependencyManagement. Gdy dependencies jest używane bez niego, nierozwiązane zależności są zauważane w pliku pom. Jeśli używane jest dependencyManagement, nierozwiązane zależności pozostają niezauważone w pliku pom, a błędy pojawiają się tylko w plikach java. (import i tym podobne...)