(неправильное) понимание зависимостей пакетов osgi

Я новичок в osgi и bndtools, но за последние пару дней мне удалось заставить создание jar->bundle работать с помощью задачи bnd ant, а также обернуть наши сторонние jar-файлы в виде пакетов (для тех, кто еще не определил «Export- Пакет» в файле манифеста). Я должен отметить, что bndtools кажется удивительным для выполнения всей тяжелой работы, когда речь идет об экспорте и импорте, поэтому спасибо вам за вашу тяжелую работу над этим проектом!

у меня есть две проблемы, которые, возможно, вы можете пролить свет:

1

Я пытаюсь загрузить пакеты в felix и сразу же сталкиваюсь с ошибками разрешения. В этом базовом сценарии у нас есть собственный пакет под названием omniquery_common, который использует несколько сторонних jar-файлов, включая gson. когда я разрешаю, я получаю это:

Unable to resolve <<INITIAL>> version=null:
   missing requirement Require[osgi.identity]{}{filter=(osgi.identity=omniquery_common)} [caused by:
   Unable to resolve omniquery_common version=1.0.0.0:
   missing requirement Require[osgi.wiring.package]{}{filter=(&(osgi.wiring.package=com.google.gson)(version>=2.2.0)(!(version>=3.0.0)))}]

Для меня это говорит о том, что omniquery_common импортирует com.google.gson (версии не ниже 2.2 и ниже 3.0). пакет gson экспортирует версию 2.2.4, так что это должно удовлетворять его зависимости, но это не так.

Можете ли вы помочь мне понять, как я подключаю это неправильно?

манифест для omniquery_common:

Manifest-Version: 1.0
Bnd-LastModified: 1442336803995
Bundle-ManifestVersion: 2
Bundle-Name: omniquery_common
Bundle-SymbolicName: omniquery_common
Bundle-Version: 1.0.0.0
Created-By: 1.8.0_40 (Oracle Corporation)
Export-Package: com.radian6.omni.common.osgi;version="1.0.0"
Import-Package: com.google.gson;version="[2.2,3)",com.radian6.omni.commo
 n.util,org.apache.commons.io;version="[1.4,2)",org.apache.commons.lang;
 version="[2.6,3)",org.junit
Private-Package: com.radian6.omni.common.core
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Tool: Bnd-2.4.1.201501161923

манифест для gson:

Manifest-Version: 1.0
Export-Package: com.google.gson;version=2.2.4, com.google.gson.annotat
 ions;version=2.2.4, com.google.gson.reflect;version=2.2.4, com.google
 .gson.stream;version=2.2.4, com.google.gson.internal;version=2.2.4, c
 om.google.gson.internal.bind;version=2.2.4
Bundle-ClassPath: .
Built-By: inder
Bundle-Name: Gson
Created-By: Apache Maven 3.0.4
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Vendor: Google Gson Project
Bundle-ContactAddress: http://code.google.com/p/google-gson/
Bundle-Version: 2.2.4
Build-Jdk: 1.7.0_21
Bundle-ManifestVersion: 2
Bundle-Description: Google Gson library
Bundle-SymbolicName: com.google.gson
Archiver-Version: Plexus Archiver

2

если я изменю порядок пакетов в списке «требования к запуску», поместив пакет gson перед omniquery_common, я получу

Unable to resolve <<INITIAL>> version=null:
   missing requirement Require[osgi.identity]{}{filter=(osgi.identity=com.google.gson)}

что я нахожу неинтуитивным - я бы подумал, что порядок пакетов в этом списке не имеет значения ...?


person Adam Morgan    schedule 17.09.2015    source источник


Ответы (1)


Порядок требований в списке -runrequirements действительно имеет значение, потому что, если в начале списка есть ошибка, мы не пытаемся решить все, что ниже. То есть: как только мы узнаем, что разрешение не может быть успешным, мы просто выходим и печатаем первую обнаруженную ошибку.

Второе сообщение об ошибке, которое вы скопировали (когда вы поставили требование GSON первым), предполагает, что у вас просто нет пакета GSON в вашем репозитории. Или его нет в репозитории, который виден распознавателю. Фильтр (osgi.identity=com.google.gson) дает сбой, что означает отсутствие ресурса с идентификатором com.google.gson.

Это также объясняет первое сообщение об ошибке из вашего собственного пакета omniquery_common. Преобразователь не может найти какой-либо пакет, экспортирующий пакет com.google.gson, что имело бы смысл, если пакет GSON отсутствует.

Итак, изучите репозитории, с которыми вы разрешаете, и что содержат их индексы. Если GSON действительно окажется там, мне потребуется дополнительная информация, чтобы выяснить проблему.

Между прочим, как только вы это заработаете, вам вообще не нужно явно указывать GSON в -runrequirements. В этом суть распознавателя: мы найдем все ваши зависимости на основе используемых вами пакетов.

person Neil Bartlett    schedule 17.09.2015
comment
Хорошо, это имеет смысл для runrequirements в этом смысле, но я думал, что где-то читал, что osgi разрешает циклические зависимости. Не помешает ли этому «короткое замыкание»? - person Adam Morgan; 21.09.2015
comment
В любом случае, я понял, что создавал отдельные дескрипторы запуска. Как только я удалил их и использовал файл bnd.bnd по умолчанию (сначала не понял, что туда можно поместить дескриптор запуска), все заработало. Тем не менее, мне все еще нужно поместить пакет в «требования к запуску», потому что он, похоже, не разрешает зависимости автоматически. В любом случае, у меня работает базовая установка, и начинается запуск BundleActivator. спасибо Нил! - person Adam Morgan; 21.09.2015
comment
Да OSGi разрешает циклические зависимости. Я не понимаю, насколько это актуально... где здесь циклическая зависимость? У вас просто полностью отсутствующий пучок. - person Neil Bartlett; 22.09.2015
comment
Да, здесь нет абсолютно никакого circ dep - это было просто ваше заявление о коротком замыкании, из-за которого это звучало так, как будто он еще не нашел зависимость, которая быстро выходит из строя. В этом случае circ dep вам нужно будет потенциально перейти в конец списка, прежде чем найти другой пакет в вашем circ dep, и короткое замыкание звучит так, как будто это предотвратит этот полный обход runrequirements. Имеет ли это хоть какой-то смысл? - person Adam Morgan; 23.09.2015
comment
Список требований верхнего уровня на самом деле не имеет значения, потому что вы можете получить цикл в любой из зависимостей n-го уровня этих требований. И резолвер обрабатывает их, просто запоминая уже посещенные ресурсы. В любом случае, я не писал преобразователь, но я знаю, что он работает, поэтому я счастлив. - person Neil Bartlett; 23.09.2015
comment
Итак, у меня все работает с автономной установкой felix. Однако, когда я возвращаюсь к bndtools в eclipse со всеми моими соответствующими пакетами, перечисленными в разделе «доступные пакеты», я получаю сообщение об ошибке об отсутствии Failed to start bundle omniquery_service-1.0.0, exception Unresolved constraint in bundle omniquery_service [6]: Unable to resolve 6.0: missing requirement [6.0] osgi.wiring.package; (osgi.wiring.package=com.radian6.buildup) пакета buildup.jar, и его манифест экспортирует com.radian6.buildup. что мне здесь не хватает? - person Adam Morgan; 25.09.2015