Pytanie W jaki sposób Maven rozwiązuje konflikty wersji przechodnich? Najbliższa strategia wygrywa


W końcu przyzwyczaiłem się do tego, że w moich projektach nie używam żadnych niezadeklarowanych lub nieużywanych deklarowanych zależności. Chociaż bardzo trudno jest śledzić nieużywane zadeklarowane zależności środowiska wykonawczego / testowego, które są wymienione w zależności: analiza ... Wystarczy napisać do nich komentarze w pom.xml lub w inny sposób zarządzać nimi, aby wiedzieć, że są one potrzebne do testowania lub wykonywania.

Ale sposób rozwiązania konfliktu wersji wciąż jest dla mnie niejasny. Odnośnie przechodnich zależności.

Jak działa strategia najbliższej wygranej? Kiedy jedna wersja jest używana w innej wersji?

  • Jeśli zadeklarujesz używaną niezadeklarowaną zależność z numerem wersji - zawsze wygrywa

  • Jeśli nie zostanie jawnie określona wersja zależności, Maven nie będzie w stanie rozwiązać żadnej wersji konflikty, które mogą powstać w związku z tą zależnością (dziwne, ale napisane) tutaj)

  • Jeśli nie zadeklarujesz zależności Undeclared, wybierzesz przejściową zależność od najbliższego poziomu (strategia najbliższego-wygrywa) i jeśli konflikt jest na tym samym poziomie, to w jakiś sposób decyduje między wersją A a wersją B ... Może pierwszą do którego dochodzi przy przetwarzaniu wygranych depenency


18
2018-06-08 19:08


pochodzenie


Jeśli chcesz zdefiniować zależność dla testu, podaj ją tylko za pomocą zakresu, który działa również w środowisku wykonawczym. - khmarbaise


Odpowiedzi:


Myślę, że rozdzielczość zależności działa dokładnie tak, jak opisałeś.

Myślę też, że twoje życie byłoby o wiele łatwiejsze, gdybyś używał <scope> dziecko tag do swojego <dependency>

jak cytuje z oficjalnej strony internetowej:

  1. skompilować: Jest to domyślny zasięg, używany, jeśli żaden nie jest określony. Kompilacje zależności są dostępne we wszystkich ścieżkach klas projektu. Co więcej, te zależności są propagowane do projektów zależnych.
  2. provided: Jest to bardzo podobne do kompilacji, ale oznacza, że ​​spodziewasz się, że JDK lub kontener zapewnią zależność w środowisku wykonawczym. Na przykład podczas budowania aplikacji WWW dla Java Enterprise Edition należy ustawić zależność od interfejsu API Servlet i powiązanych interfejsów API Java EE do podanego zakresu, ponieważ kontener WWW udostępnia te klasy. Ten zakres jest dostępny tylko w kompilacyjnej i testowej ścieżce klas i nie jest przechodni.
  3. Środowisko wykonawcze Ten zakres wskazuje, że zależność nie jest wymagana do kompilacji, ale do wykonania. Jest w środowisku wykonawczym i testuje ścieżki klas, ale nie kompiluje ścieżki klasy.
  4. test: ten zakres wskazuje, że zależność nie jest wymagana do normalnego korzystania z aplikacji i jest dostępna tylko dla fazy kompilacji testów i wykonania.
  5. system: Zakres ten jest podobny do podanego, z wyjątkiem tego, że musisz wyraźnie podać JAR, który go zawiera. Artefakt jest zawsze dostępny i nie jest wyszukiwany w repozytorium.
  6. import: (dostępne tylko w Maven 2.0.9 lub nowszym) Ten zakres jest używany tylko w zależności od typu pom w sekcji. Wskazuje, że określony POM powinien zostać zastąpiony przez zależności w sekcji POM. Ponieważ są one zastępowane, zależności z zakresem importu faktycznie nie uczestniczą w ograniczaniu przechodniości zależności.

2
2017-12-28 14:17





Istnieje kilka linków do dokumentacji zarządzania zależnościami:

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html (tabela importu w sekcji "Zakres zależności")

W niemieckim czasopiśmie znajduje się artykuł o Bogu opisujący rozwiązywanie zależności - tutaj znajduje się odniesienie do artykułu w bibtex: http://www.bibsonomy.org/bibtex/2ef10bb1bc1be7806bc3fba53417bbd5f/funthomas424242

W książce o sonacie znajduje się sekcja o wtyczce zależności: http://www.sonatype.com/books/mvnex-book/reference/optimizing-sect-dependency-plugin.html

Mam nadzieję, że to było pomocne.


1
2018-01-12 22:15