Два разных банок x, y, зависящих от разных версий z.Как пользователь может иметь оба х, у в своем приложении?

Question

Я делаю jar-файлы остальных клиентов для вызова каждого набора сервисов.За услуги -1, услуги -2, услуги-3;у нас есть соответственно clientjar1, clientjar2, clientjar3.Во всех остальных клиентских jar-файлах есть некоторые общие функции, которые я сохранил в отдельном jar-файле, то есть в «corejar1.0».Все клиентские банки зависят от "corejar1.0".

Теперь мне нужно создать новую клиентскую флягу "clientjar4" для нового набора сервисов-4.Но это не будет работать со старым "corejar1.0".Поэтому я изменил содержимое corejar и выпустил новую версию «corejar1.1».Таким образом, «clientjar4» относится к «corejar1.1», а все остальные клиенты ссылаются на «corejar1.0».Теперь, если пользователь хочет использовать и cientjar1, и clientjar4, возникнет конфликт версий bcz, они оба ссылаются на разные версии ядра jar.Таким образом, один из jar-файлов клиента может работать не так, как ожидалось.

Таким образом, одно из решений состоит в том, чтобы повторно выпустить все jar-файлы клиента, обновив их так, чтобы они указывали на новый «corejar1.1».Я чувствую, что это не очень хороший способ, потому что мы выпускаем новые версии клиентских jar-файлов, хотя в их соответствующих сервисах нет изменений.

Мой проект - это проект Java, и я использую Gradle в качестве инструмента для сборки.Кто-нибудь может предложить лучшее решение?

Answer 1

Как уже упоминалось @Andreas, вы управляете обратной совместимостью между corejar1.0 и corejar1.1.

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

Хотя это выглядит как хорошаяРешение в вашем случае, есть другие случаи, когда это не так просто.Для этого вы можете настроить способ, которым Gradle будет разрешать транзитивные зависимости и их версию.

Answer 2

Если вы убедитесь, что изменения, сделанные вами в corejar1.1, обратно совместимы с corejar1.0, то clientjar1 use corejar1.1 не проблема.

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

Если вы не можете сделать corejar1.1обратная совместимость с corejar1.0, затем необходимо развернуть обновленные версии всех клиентских jar-файлов.