Unikać konfliktów wersji zależności?

Każdy projekt Java, który korzysta z mojego jar, prawie na pewno będzie miał dodatkową zależność od innego jar, który mój jar również zawiera jako zależność.

Problem polega na tym, że inny słoik ma wiele wersji.

Jak mogę uniknąć problemów, które mogą się pojawić, na przykład w przypadku, gdy wersja 2. słoika w twoim projekcie różni się od wersji 2. słoika w moim słoju?

Nie chcę, aby moi użytkownicy mieli dodatkowy problem z wykonaniem fantazyjnej sztuczki ładowania klasy, aby dodać mój słoik.

Czy powinienem zrobić kilka różnych wersji mojego słoika dla każdej możliwej wersji tej wspólnej zależności? A potem wybierasz wersję mojego słoika, która używa tej samej wersji 2. słoika, którą już masz?

Czy istnieje mądrzejszy sposób, aby sobie z tym poradzić i ułatwić ludziom korzystanie z mojego słoika bez konfliktów?

To nie twój problem. Rozwiązanie należy do użytkownika końcowego. Po prostu pochodzi z terytorium używania zależności stron trzecich i musiałem rozwiązywać konflikty zależności więcej razy, niż liczę. Nie można oczekiwać rozwiązania konfliktów zależności między poszczególnymi projektami.

Twoje oprogramowanie powinno działać poprawnie z najnowszymi wersjami twoich zależności. O ile zależność nie zmienia interfejsu w każdym wydaniu, powinieneś mieć zakres kompatybilności (np. Twoje oprogramowanie działa dla wszystkich wersji dep w zakresie [2.0.0, 3.0.0)). Tak długo, jak utrzymujesz oprogramowanie, powinieneś starać się zachować zgodność z najnowszą wersją wszystkich swoich zależności.

To powiedziawszy, oto kilka rzeczy, które uważam za przydatne jako programista używający twojego oprogramowania z moją inną wersją twojej zależności.

• Jeśli integracja między Twoim projektem a innym projektem jest ścisła, dobrze jest mieć tabelę zgodności w dokumentacji. Niezależnie od tego w dokumentacji należy wspomnieć o znanych problemach z konkretnymi wersjami zależności. W przeciwnym razie programiści muszą znaleźć kompatybilną wersję metodą prób i błędów.
• Wyodrębnij współpracę z zależnością za pomocą interfejsu i zaprojektuj swoje oprogramowanie, aby wdrożenie można było zastąpić wstrzykiwaniem zależności. To pozwala mi, jako użytkownikowi końcowemu, zastąpić własną integrację z wersją x biblioteki bez zawracania ci głowy.
• Mieć narzędzie do publicznego śledzenia problemów, aby użytkownicy mogli poprosić Cię o wsparcie niektórych wersji wspólnej zależności. Jeśli okaże się, że wielu użytkowników chce obsługiwać niekompatybilną wersję zależności, możesz opublikować wersje dla obu. Zobacz przykład Maven, w którym są one ukierunkowane na wiele platform - obsługa różnych wersji zależności powinna być podobna.