Не применять автоматические обновления пакетов для старых пакетов

Question

Возможно ли в OSGi поддерживать проводку соединений даже через перезагрузки системы, даже если теперь есть новая, более высокая версия, мы остаемся со старой? Дело в том, что если что-то работает, мы не хотим рисковать, проводя старые пакеты в новую зависимость. Другими словами, мы стараемся изолировать обновления как можно больше, чтобы обновление в компоненте не влияло на ВСЕ другие компоненты (поскольку старые пакеты все еще используются для удовлетворения уже подключенных зависимостей)

As пример, предположим, что A зависит от B с диапазоном [1.0.0, 2.0.0). Мы развертываем версию 1.0.0 из B, поэтому теперь A подключен к B_1.0.0
Теперь мы создаем пакет C, который зависит от логического изменения, поэтому он зависит от B с диапазоном [1.0.1, 2.0.0]. Поэтому мы развертываем B_1.0.1. Теперь, если мы перезапустим систему, C и A будут подключены к 1.0.1, так как они находятся в диапазоне зависимостей обоих, и теоретически это «лучшее» совпадение для A, чем 1.0.0. Есть ли способ сказать OSGi не делать этого и держать проводки как можно дольше (скажем, до тех пор, пока старый пакет не будет удален, и в этом случае было бы нормально перейти с самой высокой версией в диапазоне)

В настоящее время мы запрещаем диапазоны, поэтому зависимости подобны [1.0.0, 1.0.0]. Это дает нам изоляцию обновлений, которую мы хотим, но за счет того, что мы в основном теряем модульность; для обновления зависимостей нам необходимо обновить иждивенцев, даже если код в иждивенцах не изменился. Я думаю, что это огромный анти-шаблон для запрета диапазонов, поэтому я пытаюсь предложить лучшую альтернативу с диапазонами, но это даст нам изоляцию обновлений, и мы должны сначала отказаться от переналадок даже во время сеансов.

Если это важно, мы не используем службы OSGi. Все они простые пучки

Answer 1

Ответ на вопрос в первом абзаце просто: да, это поведение OSGi по умолчанию. Если вы остановите и перезапустите фреймворк без каких-либо обновлений пакета или обновления пакета, тогда состояние проводки будет таким же, как и при следующем запуске.

Однако вы меняете вещи во втором абзаце. Теперь у вас есть 2 экспорта B с разными версиями, и оба A и C зависят от него, с неидентичными , но перекрывающимися диапазонами. Ключевым здесь является перекрытие. OSGi всегда пытается свести к минимуму количество независимых экспорта одного и того же пакета, поэтому, если у вас есть два пакета, импортирующих с перекрывающимися диапазонами, тогда структура попытается связать их с одной и той же версией, а не с двумя отдельными версиями. Версия, которая попадает в перекрытие здесь, равна 1.0.1, поэтому оба A и C будут подключаться к 1.0.0.

Не пытайтесь изменить это. Если расслоение A действительно совместимо с диапазоном [1.0.0, 2.0.0), то почему бы вам противопоставить его проводке до версии 1.0.1 ?? С другой стороны, если A действительно совместим только с версией 1.0.0, а не с 1.0.1, тогда вы должны указать очень ограниченный диапазон, то есть [1.0.0, 1.0.1).

И наконец ... ваш последний абзац меня огорчает. Простые связки используют услуги!