Java 8 & Отсутствует требуемая способность Требовать-Возможность: osgi.ee; фильтр = "(& (osgi.ee = JavaSE) (версия = 1,8))"

Ответ 1

Ошибка означает, что ваш комплект имеет Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))" в своем манифесте. Таким образом, это означает, что пакет будет запускаться только тогда, когда есть пакет, который предоставляет эту возможность.

В случае возможностей osgi.ee именно инфраструктура OSGi (равноденствие) должна обеспечивать эту возможность. По-видимому, это не так.

Таким образом, одним из способов было бы удалить заголовок из пакета Manifest. Другим было бы сделать возможность экспорта равноденствия. Возможно, вы могли бы просто попробовать новейшую версию равноденствия. Не уверен, что это помогает. Вы также можете попробовать установить свойство framework (используя -D): org.osgi.framework.system.capabilities = osgi.ee; osgi.ee = "JavaSE", версия: List = "1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"

Видеть

• Та же проблема в списке затмений

Ответ 2

Разделите мой опыт по переоснащению целевой платформы на основе Juno 3.8.2 для запуска тестов плагина JUnit с помощью Bundle-RequiredExecutionEnvironment ("BREE") JavaSE-1.8:

Неудачный подход 1: Фрагмент

Создание фрагмента в org.eclipse.osgi с заголовком Provide-Capability в манифесте:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: FrwJava8Support
Bundle-SymbolicName: frwJava8Support
Bundle-Version: 1.0.0.qualifier
Fragment-Host: org.eclipse.osgi;bundle-version="3.8.2"
Bundle-RequiredExecutionEnvironment: JavaSE-1.7
Provide-Capability: osgi.ee;osgi.ee="JavaSE";version:List="1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8"

Эта способность никогда не поднималась.

Неудачный подход 2: параметр запуска

Использование -Dorg.osgi.framework.system.capabilities как указано в христианском ответе.

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

-Dorg.osgi.framework.system.capabilities="osgi.ee; osgi.ee=\"JavaSE\";version:List=\"1.0,1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8\""

Такой подход мог бы работать для любого другого прецедента, кроме pde.junit. У меня все еще есть это (немного другое) исключение:

!MESSAGE Bundle com.XXX.tst.frw.common_1.0.0.qualifier [92] was not   resolved.
!SUBENTRY 2 com.XXX.tst.frw.common 2 0 2015-04-18 13:43:55.336
!MESSAGE Missing Constraint: Bundle-RequiredExecutionEnvironment: JavaSE-1.8
!SUBENTRY 1 org.eclipse.osgi 2 0 2015-04-18 13:43:55.336
!MESSAGE Bundle com.XXX.tst.frw.common.test_1.0.0.qualifier [101] was not resolved.
!SUBENTRY 2 com.XXX.tst.frw.common.test 2 0 2015-04-18 13:43:55.336
!MESSAGE Missing host com.XXX.tst.frw.common_1.0.0.

!ENTRY org.eclipse.osgi 4 0 2015-04-18 13:43:55.336
!MESSAGE Application error
!STACK 1
java.lang.IllegalArgumentException: Bundle "com.XXX.tst.frw.common" not found. Possible causes include missing dependencies, too restrictive version ranges, or a non-matching required execution environment.
    at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.getClassLoader(RemotePluginTestRunner.java:77)

Рабочий подход 3: Патч Equinox

org.eclipse.osgi пакет org.eclipse.osgi чтобы включить Luna JavaSE-1.8.profile.

1. Скопируйте файл <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile в <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile пула org.eclipse.osgi для вашей целевой платформы.
   (например, <myworkspace>\.metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.osgi_3.8.2.v20130124-134944.jar\JavaSE-1.8.profile)

2. Справочный профиль в profile.list (на самом деле это кажется необязательным):
   добавить JavaSE-1.8.profile,\ to .metadata\.plugins\org.eclipse.pde.core\.bundle_pool\plugins\org.eclipse.osgi_3.8.2.v20130124-134944.jar\profile.list

Однако для этого решения требуется разместить свой собственный репозиторий P2, содержащий пакет org.eclipse.osgi или применить патч к каждому пулу пулов рабочей области.

обсуждение

Тем не менее, существует возможность сохранить BREE на "JavaSE-1.7", совместимом с существующей версией org.eclipse.osgi 3.8.2.

В настоящее время я знаю два недостатка:

• Экспорт плагинов непосредственно из Eclipse через PDE завершается с ошибкой, если в коде используется синтаксис Java 8 (например, лямбда-выражения).
• Журнал содержит ошибки компилятора, и скомпилированный результат на самом деле разного размера по сравнению с пакетом, скомпилированным с JavaSE-1.8 BREE.

Предположительно, PDE оценивает BREE и соответственно устанавливает уровень источника компилятора, который затем приводит к "1.7" для источников Java 8. Возможно, что другие функции PDE (экспорт функций, экспорт товаров) могут иметь одинаковую проблему.

Используя Eclipse Tycho, можно вручную переопределить исходный уровень javac вместо оценки BREE пакета (выбрать JDK для компиляции). Однако также Tycho по-прежнему соответствует заданному уровню источника и BREE и отказывается компилировать код Java 8 (тестируется с помощью Tycho 0.22).

Кроме того, подход 2, скорее всего, не будет работать с экспортом пакетов PDE, по крайней мере, я не знаю о возможности передачи аргументов VM.

Обновление 29.05.2015

Мы пошли с подходом 3 и успешно исправили нашу целевую платформу, чтобы использовать Java 8 вместе с Eclipse 3.8.

Поскольку мы уже поддерживаем наш собственный репозиторий P2 со всеми плагинами Eclipse на основе 3.8, нам необходимо:

• создайте обновленную копию org.eclipse.osgi (необходимо также удалить информацию о подписке из пакета)
• создать патч для функции, который исправляет функцию org.eclipse.rcp с обновленным пакетом org.eclipse.osgi
• опубликовать новый 3.8-основанный репозиторий P2, который будет использоваться нашими рабочими станциями и сервером сборки.

Резюме

Если вы поддерживаете свой собственный репозиторий P2 для обслуживания настраиваемой целевой платформы вместо использования любого сайта обновления на основе Eclipse.org, можно сделать работу Eclipse 3.8 с Java 8.

Ссылки: ошибка Eclipse для поддержки osgi.ee

Ответ 3

Я нашел конфигурацию, которая просто работает, без особых усилий. Вы выбираете Java 8 в файле продукта, настройках проекта и пути сборки. Важным является файл манифеста. Здесь вам нужно выбрать Java 8 и Java 7. Здесь также очень важен порядок. Java 8 должен быть сверху.

Я думаю, что причина, по которой эта конфигурация работает, заключается в том, что компилятор выбирает первую JRE и поэтому может обрабатывать новый синтаксис Java 8. В пакетах eclipse проверяется, является ли одна из записей необходимой Java 7 и также удовлетворены.

Ответ 4

Легкое исправление заключается в том, чтобы включить org.eclipse.equinox.ds (декларирующие услуги равноденствия). Этот пакет времени выполнения экспортирует требуемый файл osgi.extender и, похоже, не вызывает никаких дополнительных зависимостей.

Ответ 5

Реальное и быстрое решение:

"Я отредактировал вкладку" Плагины "в" Конфигурация запуска "и проверил org.eclipse.equinox.ds и нажал" Добавить необходимые подключаемые модули ". ЭТО ФИКСИРОВАНО ".

https://bugs.eclipse.org/bugs/show_bug.cgi?id=494913#c2

Ответ 6

Я получил эту ошибку в liferay dxp. Я изменил рабочее пространство liferay, и он работает нормально.

Ответ 7

У меня такая же проблема: Отсутствует требуемая способность Требовать-Возможность: osgi.ee; фильтр = "(& (osgi.ee = JavaSE) (версия = 1,8))

Я пользуюсь Felix 5.6.10

Вот интересная вещь, которую я обнаружил: я создал два пакета test.jar, которые содержат следующий файл MANIFEST.MF

test1.jar Manifest-Version: 1.0 Bundle-Description: bundle, используемый для тестирования Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee = JavaSE; version = "1.8" Создано: 1.8.0_131 (Oracle Corporation)

test2.jar: Manifest-Version: 1.0 Bundle-Description: пакет, используемый для тестирования Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.2 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee; filter: = "(& (osgi.ee = JavaSE) (версия 1.8))" Created-By: 1.8.0_131 (Oracle Corporation)

Как вы можете видеть, эти два пакета отличаются только в Bundle-Version и как задана требуемая возможность.

В результате: test1.jar устанавливает только тонкий файл test2.jar, когда вы пытаетесь его установить, появляется сообщение о недостающем требовании.

Поэтому есть что-то об использовании фильтра в заголовке Require-Capability, который не работает в моей инфраструктуре felix osgi. Разве это не поддерживается, есть ли что-то, что мне нужно настроить для включения фильтров? Это явно не потому, что моя инфраструктура не настроена на наличие необходимой возможности osgi.ee (работает test1.jar).

Очевидно, это означает, что если я исправляю заголовок Require-Capability в пакетах сбоев, у меня есть обходное решение. (Неправильное решение, если вы устанавливаете свои пакеты из открытого хранилища.)

Ответ 8

Я нашел проблему в версии Felix 5.6.10, которая вызывала мою проблему:

"Отсутствует требуемая способность Требовать-Возможность: osgi.ee; filter =" (& (osgi.ee = JavaSE) (версия = 1.8)) "

Это код, который создает проблему. Он находится в конструкторе ExtensionManager

String pkgextra =
        "true".equalsIgnoreCase(configProps.getProperty(FelixConstants.USE_PROPERTY_SUBSTITUTION_IN_SYSTEMPACKAGES)) ?
            Util.getPropertyWithSubs(configProps, FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA) :
            configProps.getProperty(FelixConstants.FRAMEWORK_SYSTEMPACKAGES_EXTRA);
    syspkgs = ((pkgextra == null) || (pkgextra.trim().length() == 0))
        ? syspkgs : syspkgs + (pkgextra.trim().startsWith(",") ? pkgextra : "," + pkgextra);

изменил последнюю строку на:

    syspkgs = ((pkgextra == null) || (pkgextra.trim().length() == 0))
        ? syspkgs : syspkgs + (pkgextra.trim().startsWith(",") ? pkgextra.substring(1) : pkgextra);

причина, из-за которой возникает проблема, заключается в том, что в конструкторе немного дальше находим этот код:

try
{
    ManifestParser mp = new ManifestParser(
        m_logger, m_configMap, m_systemBundleRevision, m_headerMap);
    List<BundleCapability> caps = aliasSymbolicName(mp.getCapabilities());
    caps.add(buildNativeCapabilites());
    appendCapabilities(caps);
}
catch (Exception ex)
{

Без коррекции вызов конструктора ManifestParser вызывает исключение, жалуясь на то, что экспортированная возможность не может быть пустым. Эта дополнительная запятая в syspkgs заставила парсер подумать, что некоторые возможности отсутствуют.

И как только вы откажетесь в этом блоке try, вы не получите возможности хоста osgi.ee, добавленные в вашу инфраструктуру, что означает, что вы не можете разрешать запросы типа (& (osgi.ee = JavaSE) (версия = 1.8))

Чтобы быть ясным, это конкретная версия, о которой я говорю:

org.apache.felix:org.apache.felix.framework:5.6.10

Эта проблема возникает только в том случае, если вы добавляете некоторые дополнительные системные возможности в свою конфигурацию, как я. Это может объяснить, почему некоторые люди видят эту проблему, а другие - нет.

Я применил патч, и фильтры снова работают.