Как избежать karaf загрузки пакета разрешения по умолчанию

Question

Я использую karaf для запуска OSGI-пакета, который использует встроенный commons-lang3.5.jar.

Проблема в том, что когда я запускаю этот пакет, karaf автоматически загружает другой файл commons-lang3.1.jar. Я не уверен, когда он будет загружен. Но это займет мое падение пакета.

Есть ли способы удалить встроенный в karaf встроенный пакет?

Answer 1

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

инструкция bnd будет выглядеть так:

import-package:
   org.apache.commons.lang;version="[3.5,4.0)", \
   *

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

Подсказка, не встраивайте зависимости, но убедитесь, что вы зависите от повторно используемых зависимостей. С такими пакетами импорта вы можете быть уверены, что зависите от конкретной версии.

Answer 2

Как говорит Ахим, не удаляйте пакет по умолчанию, а укажите требуемый диапазон версий. Однако я бы порекомендовал вам не использовать обычный диапазон версий OSGI, а вместо этого указать [3.5.0,3.5.0].

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

Например, игнорируя все второстепенные выпуски: между выпусками 3.0 а также 3.1 из общего достояния-единственного базового уровня сообщили об изменениях API были несовершеннолетние в двух пакетах: org.apache.commons.lang3 а также org.apache.commons.lang3.exception,

Тем не менее, все пакеты были разбиты на 3.1.0,

Между от 3.1 в 3.2были внесены незначительные изменения в несколько пакетов: изменение второго второстепенного уровня на org.apache.commons.lang3и первоначальные незначительные изменения в org.apache.commons.lang3.reflect, org.apache.commons.lang3.text, org.apache.commons.lang3.text.translate, а также org.apache.commons.lang3.tuple,

Тем не менее, произошли серьезные изменения в org.apache.commons.lang3.time,

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

Другими словами: сравнивая заявленные версии пакета экспорта с более "точными" версиями пакета, основанными на обнаруженных базовых изменениях, мы имеем следующее.

Обратите внимание, что только для пакетов с незначительными изменениями "точные" номера версий пакетов отражают количество выпусков с незначительными изменениями в этом пакете, а не номер пакета какого-либо конкретного выпуска.

  Пакет | "Точный" | объявленный 
-------------------------------------------------- ----------------              
= org.apache.commons.lang3 | 3.2.0 | 3.2.0 
+ org.apache.commons.lang3.builder | 3.0.0 | 3.2.0
+ org.apache.commons.lang3.concurrent | 3.0.0 | 3.2.0
+ org.apache.commons.lang3.event | 3.0.0 | 3.2.0
+ org.apache.commons.lang3.exception | 3.1.0 | 3.2.0
+ org.apache.commons.lang3.math | 3.0.0 | 3.2.0
+ org.apache.commons.lang3.mutable | 3.0.0 | 3.2.0 
+ org.apache.commons.lang3.reflect | 3.1.0 | 3.2.0
+ org.apache.commons.lang3.text | 3.1.0 | 3.2.0
+ org.apache.commons.lang3.text.translate | 3.1.0 | 3.2.0
* org.apache.commons.lang3.time | 4.0.0 | 3.2.0
+ org.apache.commons.lang3.tuple | 3.1.0 | 3.2.0

Номер пакета является "правильным" для 1 пакета, слишком консервативным для 10 пакетов и неправильным для 1. Это остается неизменным, если мы следуем шаблону до 3,5 (со вторым скрытым основным изменением пакета времени между 3,4 и 3,5).:

Пакет | "Точный" | объявленный 
-------------------------------------------------- ----------------              
= org.apache.commons.lang3 | 3.5.0 | 3.5.0 
+ org.apache.commons.lang3.builder | 3.3.0 | 3.5.0
+ org.apache.commons.lang3.concurrent | 3.1.0 | 3.5.0
+ org.apache.commons.lang3.event | 3.1.0 | 3.5.0
+ org.apache.commons.lang3.exception | 3.2.0 | 3.5.0
+ org.apache.commons.lang3.math | 3.2.0 | 3.5.0
+ org.apache.commons.lang3.mutable | 3.2.0 | 3.5.0 
+ org.apache.commons.lang3.reflect | 3.4.0 | 3.5.0
+ org.apache.commons.lang3.text | 3.3.0 | 3.5.0
+ org.apache.commons.lang3.text.translate | 3.2.0 | 3.5.0
* org.apache.commons.lang3.time | 5.0.0 | 3.5.0
+ org.apache.commons.lang3.tuple | 3.1.0 | 3.5.0

[Я обсуждаю с некоторыми людьми из проекта COMMONS версии версий после того, как открыл проблему для commons-compress о проблемах версий OSGI. Для этого проекта каждая версия каждого пакета идентична номеру выпуска (расширенного до трех цифр), и все находятся в диапазоне [1,2).

Супер-проект "Народное достояние" завален тем, что файлы packageinfo находятся в исходной директории; возможно, потому что я добавил ручную копию файлов packageinfo из дерева src, что, по-видимому, больше не требуется. Они также предпочли бы, чтобы версии пакетов генерировались автоматически.

Я еще не объяснил должным образом, почему maven-bundle-plugin по умолчанию использовать версию выпуска для каждого пакета опасно, и что изменение версии пакета должно быть сделано человеком, который изменяет источник так, чтобы изменить версию (чтобы избежать случайные поломки изменений), при этом базовый уровень проверки служит своего рода модульным тестом.

По иронии судьбы я представил изменения как часть подготовки к объединению некоторых существенных вкладов в сжатие, которые были сделаны для того, чтобы помочь сохранить каждый объявленный пакет из maven central, чтобы проанализировать, насколько надежны номера версий пакетов, и посмотреть, сколько их может быть. сделано для того, чтобы автоматически исправить их при использовании репозитория с резервной копией базы данных (и посмотреть, есть ли какие-либо особенности ряда пакетов, которые являются предикторами надежности). ]