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

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

В качестве примера предположим, что 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. Все они простые пакеты


person Hilikus    schedule 12.08.2013    source источник


Ответы (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).

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

person Neil Bartlett    schedule 12.08.2013
comment
Нил, тогда забудь о том, что это разные диапазоны. Скажем, и A, и C зависят от B с диапазоном [1.0.0, 2.0.0). Однако, когда A был выпущен, существовал только B_1.0.0, поэтому A подключается к B_1.0.0. Затем C выпускается вместе с B_1.0.1. Я хочу, чтобы проводка A->B_1.0.0 была сохранена, а также C->B_1.0.1. Я не хочу, чтобы система теперь связывала A-›B_1.0.1. Есть ли способ заблокировать это, не запрещая диапазоны? я согласен с тем, что на основе семантического управления версиями не должно быть проблем с использованием 1.0.1, но мы должны признать, что существует риск › 0 при замене того, что работает, на что-то новое - person Hilikus; 12.08.2013
comment
о, и это делает меня еще более грустным, я должен работать с этим каждый день! - person Hilikus; 12.08.2013
comment
Если C будет добавлен позже с диапазоном [1.0.0, 2.0), тогда он должен выбрать версию 1.0.0, поскольку она уже подключена к A. Применяется та же эвристика: OSGi хочет минимизировать количество экспортов одного и того же пакета. Он также не будет перемонтировать A до тех пор, пока это не будет принудительно выполнено операцией обновления пакета. Поэтому C будет использовать ту же проводку, что и A, то есть 1.0.0. - person Neil Bartlett; 13.08.2013