Что решает Apache Cave
В настоящее время я использую karaf с артефактом в качестве своего osgi jar-репозитория. Это хорошо работает. Я сталкивался с инструментом Apache Cave для Karaf, который очень похож на хранилище, за исключением того, что он также может храниться в базе данных или другом источнике данных вместо файловой системы.
Какую ценность это обеспечивает. Каковы некоторые из случаев использования, которые могут быть решены с помощью Cave
2 ответа
Отказ от ответственности: я не участвую в разработке спецификаций OSGi или Apache Cave. Все ниже только мои выводы, основанные на личном опыте.
Apache Cave является эталонной реализацией спецификации OSGi Repository. Последнее, в свою очередь, решает проблемы обеспечения комплектов OSGi. Предполагается, что он будет работать следующим образом: он предоставляет дескриптор репозитория, который определяет набор ресурсов (обычно это пакеты), предоставляемые ими возможности и требования, которые им требуются. Эта метаинформация используется для автоматического предоставления зависимостей при развертывании какого-либо ресурса.
Подробности объясняются в спецификации https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf, раздел 132.
Ситуация с репозиторием OSGi кажется мне довольно сомнительной. Apache Cave - поставщик OSGi-репозитория, но я не нашел подходящего клиента для него. Мой вопрос, Пещера Караф против org.apache.felix.bundlerepository, до сих пор остается без ответа.
Есть несколько альтернатив. Apache Felix имеет собственную реализацию (org.apache.felix.bundlerepository), которая очень похожа по концепции, но не полностью совместима со спецификацией (информация может быть устаревшей и нуждается в проверке). Караф решает ту же проблему с объектом Особенности.
Какую ценность это обеспечивает? Какие примеры использования могут быть решены с помощью Cave?
Cave используется для хранения Repositories которые содержат важную информацию (такую как местоположение, версия, требования, возможности, ...) о связках (или артефактах в целом). Это одна из 3 важных частей в процессе решения. Другие 2 Resolver а также Resolve Context,
Resolver это то, что вы можете знать из среды выполнения OSGi. Это то, что говорит вам, удовлетворены ли требования вашего пакета (чтобы его можно было запустить). Для этого он говорит с Resolve Context узнать, что доступно, что ожидается, что необязательно и т. д. Resolve Context будет в свою очередь проконсультироваться с одним или несколькими Repositories узнать, какие пакеты доступны. Довольно часто это только пакеты, установленные во время выполнения. Однако возможно иметь среду выполнения, которая будет использовать Repository ссылаясь на внешние артефакты, которые могут быть установлены при Resolver определяет, что они нужны.
Примерно такая же концепция может быть использована во время сборки. Bnd проект, например, позволяет определить .bndrun файлы, которые являются своего рода версией на основе свойств Resolve Context, Одна из вещей, которую вы можете предоставить внутри них, Repositories которые имеют информацию о доступных комплектах. Такие хранилища могут обслуживаться Cave (или что-нибудь еще, включая локальный файл XML). Основываясь на этой информации Bnd может собрать для вас среду выполнения (скажите, какие пакеты вам нужны, исходя из того, какие пакеты вы хотите запустить).
Более того, Cave может выступать в качестве репозитория Maven или прокси для других репозиториев Maven. Это удобно, как вы могли бы использовать Cave в качестве "единой точки контакта" для обоих Resolver и традиционные зависимости Maven.