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

Question

Я использую Eclipse Luna win32.x86_64 с Java 8.

Здесь из Help Menu > About > Installation Detail > Configuration Tab:

java.runtime.version=1.8.0_05-b13
java.version=1.8.0_05

Я создал новый проект плагина, запрашивая JavaSE-1.8 как среда выполнения:

в myplugin/META-INF/MANIFEST.MF файл у меня конечно:

 Bundle-RequiredExecutionEnvironment: JavaSE-1.8

Я использую этот плагин в файле продукта. Когда я пытаюсь проверить это, я получаю следующую ошибку:

Конечно, если я запускаю продукт, я получаю:

!ENTRY org.eclipse.osgi 2 0 2014-07-10 08:14:22.042
!MESSAGE One or more bundles are not resolved because the following root constraints are not resolved:
!SUBENTRY 1 org.eclipse.osgi 2 0 2014-07-10 08:14:22.043
!MESSAGE Bundle update@********/myplugin/ was not resolved.
!SUBENTRY 2 myplugin 2 0 2014-07-10 08:14:22.044
!MESSAGE Missing required capability Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE)(version=1.8))".

---

Я пытался многое проверить:

Настройки> Java > Установленные JRE

Предпочтения> Java > Установленные JRE> Среды Excution

Предпочтения> Java > Компилятор: уровень соответствия JDK Compliance Compiler

Когда я запускал продукт, я проверял на вкладке Launching, что я использую jre8 в качестве среды выполнения.

Я даже пытался изменить Java Runtime Environment в Run Configurations Диалог:

Я пробовал разные настройки. Ни один из них не работает.

---

Что случилось?

Это известная проблема?

Answer 1

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

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

Поэтому одним из подходов было бы удалить заголовок из вашего комплекта Manifest. Другой - сделать экспорт равноденствием. Возможно, вы могли бы просто попробовать с новейшей версией равноденствия. Не уверен, что это поможет, хотя. Вы также можете попытаться установить свойство фреймворка (используя -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"

Увидеть

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

Answer 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: Патч Равноденствие

Патч org.eclipse.osgi пачка, чтобы включить Луны JavaSE-1.8.profile,

1. Копировать файл <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,\ в .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 Bug для поддержки osgi.ee

Answer 3

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

Answer 4

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

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

Answer 5

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

"Я отредактировал вкладку" Плагины "в" Конфигурации запуска "и проверил файл org.eclipse.equinox.ds и нажал" Добавить обязательные плагины ". Это исправило его".

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

Answer 6

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

"Отсутствует требуемая возможность Require-Capability: 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

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

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

Answer 7

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

Я использую Феликс 5.6.10

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

test1.jar Manifest-Version: 1.0 Bundle-Description: комплект, используемый для тестирования Bundle-SymbolicName: com.phinneyridge.testbundle Bundle-Version: 0.0.1 Bundle-Name: testbundle Bundle-ManifestVersion: 2 Require-Capability: osgi.ee=JavaSE; версия ="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 Требуемое-возможность: osgi.ee;filter:="(&(osgi.ee=JavaSE)(версия 1.8))" Создано: 1.8.0_131 (Oracle Corporation)

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

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

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

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

Answer 8

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