Рекомендации по совместимости между выпусками платформы OSGi

Question

Предполагая, что это даже возможно, каковы были бы ваши рекомендации по созданию пакета, совместимого между различными выпусками платформы? Особенно между R3 и R4.

Обновление о моих требованиях:

Идея состояла в том, чтобы разработать веб-интерфейс для встроенного устройства, которое в настоящее время работает с контейнером OSGi R3, но в скором времени его можно обновить до R4 (у нас нет большого контроля над этим). Веб-интерфейс будет развернут с использованием службы OSGi HTTP. Я вижу три варианта:

• Сделайте приложение с R4, поскольку я видел, что некоторые веб-инструментарии не работают со старыми выпусками. Я полагаю, что поставщики устройства могут развернуть текущие пакеты R3 на R4 без особых усилий (но не уверены).
• Реализация веб-интерфейса с R3 и без преимуществ современных веб-инструментариев (или порекомендуйте мне один).
• Сделайте это с некоторыми пакетами R4, но в некоторой степени независимыми от выпуска, чтобы мы наконец смогли развернуть его на R3 или R4.

Answer 1

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

Продолжение:

С точки зрения HttpService, нет больших изменений, переходящих с R3 на R4.2. Первый использует спецификацию 1.1 HttpService, последний 1.2. Различия незначительны (спецификация использует теги @since в документации API, чтобы объяснить, какие методы были введены, когда).

Совершенно верно, что пакеты R3 работают так же, как и на R4. Имейте в виду, что на практике вы можете обнаружить ошибки при запуске комплектов R3 в R4. Когда только что выпустили R4, я переместил большой проект с R3 на R4, и мы столкнулись с множеством мелких проблем, по нашей собственной вине, которые привели к сбою пакетов на R4, когда они успешно работали на R3. В основном это было связано с реализациями R4, в целом они были более строгими, когда речь шла о делегировании их родительскому загрузчику классов. Убедитесь, что вы тестируете свои пакеты на платформах, на которых вы хотите их развернуть.

Мне интересно, каким образом веб-инструментарий, на который вы смотрели, не работает на R3? Они зависят от HttpService 1.2? Я думаю, что не составит труда запустить 1.2 на R3 самостоятельно или подключить его к реализации 1.1.

Answer 2

Я разработал пакеты с R1, и они все еще работают на платформах R4.Обратная совместимость является важным моментом для работы над спецификацией.Но, как отмечает Марсель, вам могут помочь некоторые подробности ваших требований.

Обновление Существуют ли деловые или технические требования, по которым вы не можете использовать R4?Что ж, если вы просто реализуете службу на основе сервлетов, используя стандартную службу HttpService, вам не следует ожидать каких-либо проблем при переносе пакета в среду R4.Однако вы можете и должны начать использовать свойства манифеста R4.Они игнорируются в R3, но очень полезны при разрешении зависимостей в R4 и более поздних версиях.

Если вы ограничены средой R3, я всегда буду регулярно выполнять тестовый прогон на платформе R4 параллельно, чтобычто все еще хорошо.Совсем немного усилий.