Ograniczanie przechodniego zależności do zakresu czasu działania w Maven

Question

Mam 2 projekty korzystające z Maven. Pierwszy to biblioteka zawierająca klasy i metody użytkowe. Drugi projekt jest rzeczywistą aplikacją, która ma bibliotekę jako zależność. Moja biblioteka używa wewnętrznie biblioteki innej firmy.

Więc to są zależnościami:

• Moja biblioteka: zależy od biblioteki trzeciej
• mój wniosek: zależy od mojej bibliotece

Jednak nie chcę biblioteki klas firm trzecich dostępne w czasie kompilacji w mojej aplikacji. Jest tak dlatego, że aplikacja jest obsługiwana przez duży zespół i chcę zapobiec przypadkowemu użyciu metod z zewnętrznej biblioteki w aplikacji, ponieważ niektóre nazwy klas i niektóre nazwy metod są podobne między tymi dwoma. Oczywiście trzecia biblioteka będzie musiała być dostępna w mojej aplikacji pod adresem runtime.

Jeśli zakres dla wszystkich moich zależności byłby skompilować, nie osiągnąłby mojego celu. Czy jest sposób na osiągnięcie tego w Maven 3?

Answer 1

Bardzo dobre pytanie i niestety nie można tego zrobić przy użyciu Maven 3 lub 2, lub jakiejkolwiek innej wersji, ze względu na jej podstawowy projekt. To, o co pytasz, jest właściwie pożądanym i idealnym zachowaniem, ponieważ w rzeczywistości każda zależność artefaktów musi być przechodnia z zasięgiem runtime. Jednak takie projektowanie prowadzi do pewnych problemów. Jak można przeczytać na Maven's Introduction to the Dependency Mechanism o compile zakresie:

Zakłada się, że powinno to być zakres wykonawczego zamiast, tak że wszystkie kompilacji zależności muszą być wyraźnie wymienione - jednak nie jest przypadek gdzie biblioteka polegać on rozszerza klasę z innej biblioteki , zmuszając cię do udostępnienia w czasie kompilacji. Z tego powodu , zależności kompilacji czasu pozostają jako zakres kompilacji, nawet gdy są one przechodnie.

Tak więc, jak widzisz, to, czego potrzebujesz, to właściwie właściwy projekt tego zachowania, którego niestety nie można zrealizować.

Answer 2

Nic się nie zmieniło w ciągu ostatnich trzech lat, więc odpowiedź Michała jest nadal poprawna: Nie ma sposobu na ograniczenie widoczności przechodni w Maven.

Należy jednak rozważyć przeprojektowanie biblioteki, aby podzielić ją na api-artefakt, który jest niezbędny jako zależność od czasu kompilacji i który sam w sobie nie zależy od biblioteki strony trzeciej i artefaktu implementacji, który jest potrzebny tylko jako zależność czasu wykonywania i która zależy od biblioteki strony trzeciej.

Answer 3

W aplikacji można zadeklarować jawną zależność od biblioteki innej firmy przy użyciu zakresu "środowisko wykonawcze".

Zapobiega to wyświetlaniu biblioteki innej firmy w czasie kompilacji, a zatem nie można w niej wkraść żadnych bezpośrednich użytków. Jednak będzie ona nadal obecna w czasie wykonywania (ponieważ jest potrzebna w bibliotece).

To działa, ale jest niezręczne i zasługuje na objaśniający komentarz XML w pom.

Answer 4

Inne odpowiedzi są poprawne. Oprócz pracy wokół wokół brakującego ważna cecha w Maven przez dzielenie się sztuczną moduł API tylko, masz również te alternatywy:

• wyklucza przechodnie zależności, następnie od nich zależy bezpośrednio (trzeba zarządzać numerów wersji samodzielnie)
• Użyj kontrolki importu checkstyle i CI. W ten sposób członkowie zespołu mogą korzystać z funkcji tranzytu, ale wtedy testowanie zakończy się niepowodzeniem.
• Użyj gradle. Jest to rozwiązanie do wielu ograniczeń Maven

Answer 5

Można analizować zależności z: mvn dependency:analyze lub mieć zależności analizowane jako część weryfikacji fazy cyklu życia: https://maven.apache.org/plugins/maven-dependency-plugin/examples/failing-the-build-on-dependency-analysis-warnings.html