Обнаружение (Eclipse) ошибки OSGI «использует конфликт»
Решение большого связанного дерева, которое имеет конфликт, является утомительной работой.
Самая простая ошибка, которую нужно решить - «Отсутствует ограничение». Это просто отсутствующий пакет или класс, и в ошибке явно указывается, какой пакет / пакет Java отсутствует.
Я хочу сосредоточиться на загадочном сообщении об ошибке OSGI, которое называется «использует конфликт».
Инструменты Equinox OSGI не предоставляют много информации об именах пакетов, которые создают конфликт версий. Существует множество работ, объясняющих, как разрешить конфликт, однако ни одна из них не показывает, как быстро найти пакет, конфликтующий с конфликтом.
Вот метод, чтобы определить, какая версия пакета + вызывает конфликт.
Начнем с некоторого воображаемого проекта: разработчик написал плагин Eclipse + несколько пакетов (JAR).
Плагин содержит в основном код пользовательского интерфейса, а файлы JAR содержат в основном разделяемую / повторно используемую логику.
Разработчик упаковал их все в функцию Eclipse и пытается установить ее.
Из-за «использования-конфликта» плагин не запускается.
У вас есть плагин. Вы устанавливаете, но он не запускается из-за конфликта использования
закрыть затмение
повторно запустите eclipse через командную строку (linux):
./eclipse -console -consoleLog -data /tmp/eclipseTest/workspace/ -clean
(пользователи win32 должны вызывать eclipse.exe из курса)
Эта команда выведет на консоль osgi, которая нам понадобится позже.
когда завершится загрузка eclipse, вернитесь в окно командной строки eclipse. вы должны увидеть там командную строку «osgi>» (если не дважды нажмите Enter)
найдите пакеты Java вашего плагина / пакетов. давайте предположим, что он назван com.A, B, C, D и E
запустить в консоли osgi:
osgi> ss com.A
id State Bundle
7 INSTALLED com.A
osgi> start 7
org.osgi.framework.BundleException: Пакет "com.A [7]" не может быть разрешен. Причина: конфликт использует пакет: Require-Bundle: com.B; пачка версия = «0.0.0»
в org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError ... больше стека здесь ...
Теперь мы знаем, что пакет, который com.A зависит от пакета com.B, и что com.B имеет конфликт. Причина, конечно, в конфликте питательного использования. (примечание: фактический конфликт может быть скрыт даже дальше: в каком-то другом пакете, от которого зависит com.B, но давайте пока проигнорируем это)
Идеальное состояние, к которому мы хотим прийти:
osgi> ss com.A
Framework is launched.
id State Bundle
7 ACTIVE com.A
но мы еще не там.
поэтому мы знаем, что комплектация com.B проблематична.
мы можем увидеть список импорта, который он пытается загрузить (но не может), запустив
osgi> bundle 10
(10 - это случайный идентификатор пакета, который наш com.B-пакет получил из контейнера OSGI. Просто запустите в консоли osgi: «ss com.B», чтобы найти его идентификатор пакета)
сосредоточиться на разделе «Импорт-пакет». скопируйте это куда-нибудь.
При установке плагина в инфраструктуру eclipse он фактически распаковывается в каталог плагинов eclipse. Откройте проводник и перейдите в / plugins. Найдите каталог «плохого» пакета (тот, который использует «конфликт использования»). Вероятно, он будет называться com.B. [version_or_timestamp].
развернуть до каталога META-INF. отредактируйте файл manifest.mf: начните с очистки раздела «Импорт-пакеты» (вырезайте и вставляйте эту часть в блокнот)
перезапустите затмение (Ctrl + C для выхода из запущенного затмения в консоли osgi, а затем снова запустите)
Теперь затмение должно сказать, что расслоение «АКТИВНО». если он не запускался в активном режиме, возможно, произошла ошибка Missing-Constraint. Это легко решить, поскольку ошибка в значительной степени информативна, но здесь это не главное.
До повторного всплытия конфликта использования: начните повторное заполнение раздела Import-packages в этом манифесте до его исходного состояния. Делайте это по одному пакету Java за раз, чтобы вы могли точно определить, какие изменения вызывают «конфликт использования»
при редактировании manifest.mf в блокноте убедитесь, что вы нажали Enter в столбце 71, и следующая строка начинается с одного пробела. Как вы могли заметить, манифест имеет ту уникальную структуру новой строки, которой вы должны следовать.
перезапустите eclipse (Ctrl + C в консоли osgi, затемперезапустите).
Повторно проверьте состояние комплектов, выполнив команду osgi «ss com.A», попробуйте «запустить com.A» и посмотрите, нет ли ошибок.
перезапускать затмение после каждого изменения manifest.mf, как указано выше.
Как только вы добавите неверный импорт java в ваш manifest.mf, вы получитеувидит, что пакет помечен только как «РАЗРЕШЕННЫЙ» (а не активный).Предположим, что первый найденный вами пакет java для взлома пакета - это javax.xml.bind.запустите в консоли OSGI: «packages javax.xml.bind», и вы должны увидеть список разрешенных пакетов OSGI + версии + использование для этого пространства имен.если вы получили более одного провайдера (т.е. более одной версии - это дерево. посмотрите на его корни), вам может понадобиться изменить исходный пакет и заставить его импортировать конкретную версию (используя директиву «version» в Import-Package section. Например, javax.xml.bind; version = "[2.1,3)" это говорит osgi о поиске диапазона) Обычно, если вы пишете пакет OSGI или плагин Eclipse, лучше всего указыватьИмпортируйте диапазон версий по возможности явно (и не используйте значение по умолчанию, равное 0.0.0 или любую другую версию) в заголовках пакета импорта.То же правило применимо и к директиве use: =, которая иногда используется внутри заголовка Import-Package.
То же самое относится к заголовку Require-Bundle: лучше всего использовать директиву OSGI «bundle-version», чтобы убедиться, что выполучить версию, которую вы ожидаете.Если Maven используется в процессе сборки, это еще более важно, поскольку позволяет maven правильно вычислять зависимости от версии (особенно если используется Felix maven-bundle-plugin)
Другая проблема заключается в том, что вы иногда запрашиваете в манифесте вашего пакета.: Import-Package: javax.xml.bind; version = ”[2.1.9,3)”, но по какой-то причине это не может быть выполнено.Вы можете расширить свой диапазон версий, если это возможно.
Когда вы разрешили конфликт OSGI, не забудьте соответствующим образом отредактировать исходные манифесты / сценарии сборки.
комментарий на комментарий: вы можететакже попробуйте запустить «eclipse.exe -clean», который может правильно пересчитать зависимости пакета и позволит запустить ваш плагин, но это не является долгосрочным решением.