Как лучше всего сгруппировать пакеты OSGi для создания согласованного «приложения»

«Путь OSGi» заключается в разработке отдельных пакетов, содержащих дискретные, согласованные части функциональности. Иногда эти пакеты содержат служебные классы, иногда они зависят от служебных классов и настраивают свои собственные службы OSGi.

Пользователи, с другой стороны, вряд ли будут подвергаться воздействию пакетов. Они больше заботятся о приложении , части программного обеспечения, которая выполняет задачу или решает их проблему. Обычно приложение будет использовать несколько пакетов (, скажем, импортированных через Import -Package )для выполнения своих задач.

Каков наилучший способ формализовать эти отношения в мире OSGi? Одним из примеров требований может быть что-то такое же простое, как отображение номера текущей версии приложения(не пакет (с ))для пользователя. Как узнать этот номер версии?

В Eclipse есть концепция под названием «функции», но это не стандарт OSGi.

Питер Кринс написал о приложениях OSGi , и его статья имеет смысл. Мой вывод заключался в том, что приложение может сопоставляться с пакетом; просто этот пакет каким-то образом использует другие пакеты. Но если нужно создать пакет приложений с помощью Import -Package, я не понимаю, как это может быть осуществимо с точки зрения разработки.

Одним из способов может быть наличие «пакета приложений», который использует Require -Bundle и имеет свою собственную версию, но Require -Bundle не одобряется в мире OSGi.

Использование Import -Package для импорта всех необходимых пакетов с требуемыми версиями, однако, добавляет значительные накладные расходы на обслуживание для разработчика до такой степени, что я не думаю, что это возможно.Каждый раз, когда вносятся самые маленькие изменения, даже в пакет реализации, версия пакета должна обновляться, а затем зависимость от версии пакета обновляется в «пакете приложений».