Что решает пещера Apache

В настоящее время я использую karaf с Artifextory в качестве репозитория osgi jar. Это хорошо работает. Я столкнулся с инструментом Apache Cave для Karaf, который очень похож на репозиторий, за исключением того, что его также можно хранить в базе данных или другом источнике данных вместо файловой системы.

Какую ценность это дает. Какие варианты использования можно решить с помощью Cave?


person Tapan Chandra    schedule 31.03.2017    source источник


Ответы (2)


Отказ от ответственности: я не участвую в разработке спецификаций OSGi или Apache Cave. Все нижеизложенное — это только мои выводы, основанные на личном опыте.

Apache Cave является эталонной реализацией спецификации репозитория OSGi. Последнее, в свою очередь, решает проблемы предоставления пакетов OSGi. Предполагается, что он работает следующим образом: он предоставляет дескриптор репозитория, который определяет набор ресурсов (обычно это пакеты), предоставляемые ими возможности и требуемые требования. Эта метаинформация используется для автоматического предоставления зависимостей при развертывании некоторого ресурса.

Подробности описаны в спецификации https://osgi.org/download/r6/osgi.cmpn-6.0.0.pdf, раздел 132.

Ситуация с репозиторием OSGi мне кажется довольно сомнительной. Apache Cave является поставщиком репозитория OSGi, но я не нашел для него подходящего клиента. Мой вопрос, Karaf Cave vs org.apache.felix.bundlerepository, до сих пор остаются без ответа.

Есть несколько альтернатив. У Apache Felix есть собственная реализация (org.apache.felix.bundlerepository), очень похожая по концепции, но не полностью совместимая со спецификацией (информация может быть устаревшей и требует проверки). Karaf решает ту же проблему с помощью объекта Features.

person skapral    schedule 01.04.2017
comment
Насколько я знаю, эталонная реализация спецификации репозитория OSGI (обычно называемой R5) является (или, по крайней мере, была) jbosgi-repository (github.com/jbosgi/jbosgi-repository) - person Milen Dyankov; 04.04.2017
comment
Интересно, хотя документации не хватает. - person skapral; 04.04.2017
comment
См. slideshare.net /мФрэнсис/ - person Milen Dyankov; 04.04.2017

Какую ценность это дает? Какие варианты использования можно решить с помощью Cave?

Cave используется для хранения Repositories, которые содержат важную информацию (такую ​​как расположение, версия, требования, возможности и т. д.) о пакетах (или артефактах в целом). Это одна из трех важных частей в процессе разрешения. Остальные 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.

person Milen Dyankov    schedule 04.04.2017