Избежать конфликтов версий зависимостей?

Любой проект Java, который использует мой jar, почти наверняка будет иметь дополнительную зависимость от другого jar, который мой jar также содержит в качестве зависимости.

Проблема в том, что у другой банки есть несколько версий.

Как я могу избежать каких-либо проблем, которые могут возникнуть, в том случае, если вероятная версия 2-й банки вашего проекта отличается от версии 2-й банки моей банки?

Я не хочу, чтобы у моих пользователей были лишние хлопоты по поводу того, чтобы сделать какой-нибудь хитрый трюк с загрузкой классов, чтобы добавить мою банку.

Должен ли я просто сделать несколько разных версий своего фляги для каждой возможной версии этой общей зависимости? И тогда вы просто выбираете версию моей банки, которая использует ту же версию второй банки, которая у вас уже есть?

Есть ли более разумный способ справиться с этим и сделать так, чтобы людям было проще использовать мой сосуд без конфликтов?

Это не твоя проблема. Это зависит от вашего конечного пользователя. Это просто связано с использованием сторонних зависимостей, и мне приходилось разрешать конфликты зависимостей чаще, чем я считаю. Вы не можете рассчитывать на то, чтобы учесть конфликты зависимостей каждого проекта.

Ваше программное обеспечение должно работать правильно с последними версиями ваших зависимостей. Если зависимость не меняет их интерфейс в каждом выпуске, у вас должен быть диапазон совместимости (например, ваше программное обеспечение работает для всех версий в диапазоне [2.0.0, 3.0.0)). Пока вы поддерживаете программное обеспечение, вы должны стараться поддерживать его совместимость с последней версией всех ваших зависимостей.

Тем не менее, вот некоторые вещи, которые я нахожу полезными как разработчик, использующий ваше программное обеспечение с моей другой версией вашей зависимости.

• Если интеграция между вашим проектом и другим проектом тесная, полезно иметь таблицу совместимости в вашей документации. Независимо от этого, вы должны упомянуть любые известные проблемы с конкретными версиями зависимости в вашей документации. В противном случае разработчики должны найти совместимую версию методом проб и ошибок.
• Абстрагируйте взаимодействие с зависимостью через интерфейс и спроектируйте свое программное обеспечение так, чтобы реализация могла быть заменена внедрением зависимости. Это позволяет мне как конечному пользователю заменить свою интеграцию на версию x библиотеки, не беспокоя вас.
• Установите общедоступный трекер, чтобы ваши пользователи могли попросить вас поддержать определенные версии общей зависимости. Если вы обнаружите, что многим пользователям нужна поддержка несовместимой версии зависимости, вы можете опубликовать версии для обеих. Посмотрите этот пример Maven, где они предназначены для нескольких платформ - поддержка разных версий зависимости должна быть одинаковой.