Java 8 & отсутствует необходимая возможность Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE) (версия = 1.8))"

обмен опытом по модернизации целевой платформы на основе Juno 3.8.2 для запуска тестов плагинов JUnit с Bundle-RequiredExecutionEnvironment ("Бри") 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 bundle для включения Луны JavaSE-1.8.profile.

1. скопировать <LUNA>\plugins\org.eclipse.osgi_3.10.1.v20140909-1633.jar\JavaSE-1.8.profile для вашей целевой платформы bundle пула 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 bundle или применение патча к пулу пакетов каждого рабочего пространства.

Обсуждение

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

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

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

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

используя Затмение Тайхо, можно вручную переопределить исходный уровень 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 bundle
• публикации новый 3.8-хранилище Р2, потребляемой наши рабочие станции и сервер сборки.

резюме

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

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

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

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

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

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

"я отредактировал вкладку плагинов в конфигурации запуска и проверил org.затмение.равноденствие.ds и нажмите "Добавить необходимые плагины". ТО."

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

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

У меня такая же проблема: отсутствует необходимая возможность Require-Capability: osgi.ee; filter="(&(osgi.ee=JavaSE) (версия=1.8))

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

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

test1.сосуд Манифест-Версия: 1.0 Bundle-описание: bundle используется для тестирования Bundle-SymbolicName: com.финниридж.testbundle Бандл-Версия: 0.0.1 Bundle-Имя: testbundle Пакет-ManifestVersion: 2 Require-возможность: osgi.ee=JavaSE; version= " 1.8" Создано-По: 1.8.0_131 (Oracle Corporation)

условие_2.сосуд: Манифест-Версия: 1.0 Bundle-описание: bundle используется для тестирования Bundle-SymbolicName: com.финниридж.testbundle Бандл-Версия: 0.0.2 Bundle-имя: testbundle Пакет-ManifestVersion: 2 Требовать-возможность: osgi.ee; filter:= " (&(osgi.ee=JavaSE) (версия 1.8))" Создано-По: 1.8.0_131 (Oracle Corporation)

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

результат: тест1.jar устанавливается просто отлично условие_2.jar выдает недостающее сообщение требования при попытке установить его.

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

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

Я нашел проблему в версии 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 contructor вызывает исключение, жалуясь, что экспортируемая возможность не может быть пустой. Эта дополнительная запятая в syspkgs заставила парсер подумать, что некоторые возможности отсутствуют.

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

просто для ясности, это конкретная версия, о которой я говорю:

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

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

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