2016-02-13 18 views
6

Mam aplikację internetową, w której w zależności ciągnąć dwóch słoikach zwane:Maven - Wiele wersji tego samego uzależnienia

  1. javassist-3.9.0.GA.jar
  2. javassist-3.20.0-GA .jar

kiedy pakuję WAR Mam oba te elementy w katalogu WEB-INF/lib, moje pytanie brzmi, że aplikacja działa i dlaczego nie dostanę żadnych problemów, ponieważ podobno mam te same klasy w obu słoikach i powinno być problemów? prawda?

+1

Jeśli naprawdę masz dwie wersje tego samego artefaktu w swojej "wojnie", robisz coś nie tak ... z domyślną wtyczką Mavena i maven-war nie powinna nigdy mieć duplikatu pliku jar w twoim folderze lib .... (brzmi to jak robienie rzeczy ręcznie, co powinno pozostawić maven) ... – khmarbaise

+0

Dzięki, jeśli używam celu "paczki" do zbudowania pliku wojennego, czy nie używa on wtyczki maven war do tego? jeśli nie, to co innego maven-war-plugin robi z celem "pakowania"? –

+0

'pakiet' nie jest celem To jest cykl życia Jeśli ustawiłeś poprawną' war 'w twoim pliku pom to powinno to działać po wyjęciu z pudełka ... Najlepiej byłoby zobaczyć plik pom, którego używasz. – khmarbaise

Odpowiedz

14

Dla języka Java nie ma znaczenia, ile wersji klasy zapewnisz. Domyślny program ładujący klasy po prostu wybierze pierwszy w ścieżce klasy, którą może znaleźć.

Ponieważ można uruchomić aplikację bez błędu oznacza to jedną z następujących czynności:

  • jeśli javassist-3.9.0.GA.jar jest pierwszym na ścieżce klas: aplikacja nie polegać na nowy Interfejsy API lub poprawki błędów w javassist-3.20.0-GA.jar Również nie zmieniono interfejsów API używanych w tej bibliotece między tymi wersjami (których biblioteka nie powinna robić między mniejszymi wersjami)

  • , jeśli javassist-3.20.0-GA .jar jest pierwszym na ścieżce klasy: biblioteka jest kompatybilna wstecznie

Proponuję:

  • Jeśli te zależności są bezpośrednie zależności w różnych częściach aplikacji, upewnij się, że używasz wszędzie tę samą wersję. Najlepszym sposobem jest naprawienie wersji w sekcji dependencyManagement macierzystego POM, a następnie pominięcie atrybutu wersji w sekcjach zależności.
  • Jeśli zależności te są przejściowymi zależnościami, należy wykluczyć tę, której nie chcesz używać, aby upewnić się, że w ostatecznej aplikacji znajduje się tylko jedna wersja biblioteki. Rozważ także zgłoszenie problemu dla projektu, który nadal używa starej wersji i poproś ich o uaktualnienie wersji zależności.
  • Jeśli potrzebujesz pracować z dwiema niekompatybilnymi wersjami tej samej biblioteki, które mają takie same nazwy pakietów i klas, rozważ użycie systemu modułowego, takiego jak OSGi, który w pewnym stopniu obsługuje uruchamianie różnych wersji tej samej biblioteki.
+0

Rozumiem to i jego logiczne wytłumaczenie, ale nie oznacza to, że aplikacja jest naprawdę zagrożona, ponieważ jeśli mam zależność, która opiera się na klasie z wersji 3.9.0.GA i ta klasa została zaktualizowana w wersji 3.20 .2-GA, a także 3.20.0-GA jest pierwszym i na ścieżce klas, a ta zależność potrzebuje wersji tej konkretnej klasy w 3.9.0.GA? –

+0

Kolejnym pytaniem jest, jak dowiedzieć się, który z nich jest pierwszy w ścieżce klas? –

+0

Nie możesz dowiedzieć się, która jest pierwsza ... To jest poważny problem w Twojej aplikacji ... Napraw to. Inaczej może działać aplikacja, a czasami zawiedzie ... – khmarbaise

2

Odpowiedzi na "wszelkie sugestie, jak to naprawić?" spójrz na Resolving conflicts using the dependency tree. Za pomocą polecenia mvn dependency:tree będziesz wiedział, skąd bierze się jakakolwiek zależność. Kiedy wiesz, które artefakty zależą od javassist, możesz dodać wpis wykluczający, aby uniknąć jednej z wersji javassist.

Powiązane problemy