Как создается файл MANIFEST в моем комплекте AEM osgi? - PullRequest
Новая
       52

Как создается файл MANIFEST в моем комплекте AEM osgi?

0 голосов
/ 28 июня 2018

Я создал один проект maven с aem-project-archetype версией 13. После установки пакета в AEM я получаю сообщение об ошибке в консоли felix, что 3 из импортированных пакетов could not be resolved. Я пытаюсь выяснить, откуда они включены в мой файл манифеста, который находится в папке target / MANIFEST. чтобы я мог изменить версии соответствующих комплектов.

ошибка, которую я получаю в консоли felix, мой пакет находится в установленном состоянии, не активен 

org.apache.sling.api.resource,version=[2.10,3) -- Cannot be resolved
org.apache.sling.api.servlets,version=[2.2,3) -- Cannot be resolved
org.apache.sling.models.annotations,version=[1.4,2) -- Cannot be resolved

Ответы [ 2 ]

0 голосов
/ 28 июня 2018

При разработке приложений AEM комплект OSGI (и Manifest) обычно создается с помощью Felix maven-bundle-plugin .

Плагин записывает ваш пакет imports на основе java-пакетов, которые вы импортируете во весь ваш Java-код. Если вы импортируете из зависимости maven, скажем, Sling, версией для этого импорта будет версия пакета из Sling.

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

  1. Импортируемый пакет не существует в OSGI (экземпляр AEM)
  2. Существует несоответствие между версией в ваших зависимостях maven и версией в OSGI (экземпляр AEM). Следовательно, OSGI не может разрешить импортируемую вами версию.

2., скорее всего, так, потому что стропа всегда в комплекте с AEM.

Что вы можете сделать, чтобы отладить / исправить?

  1. Вы можете перейти к http://localhost:4502/system/console/depfinder и попробуйте свои пакеты там, чтобы увидеть, какая версия на самом деле экспортируется в ОСГИ.
  2. Проверьте, какие версии ваших зависимостей у вас есть в pom.xml и убедитесь, что версия OSGI находится в диапазоне, указанном явный импорт. Вы можете использовать Maven дерева зависимостей , чтобы перечислить все ваши зависимости и их версии.
  3. Это специфично для AEM, если вы используете uber-jar, убедитесь, что вы используя правильную версию для правильного экземпляра AEM вы работает.

Обратите внимание, что при импорте в манифесте диапазон [2.10,3) означает, что он принимает все версии от 2.10.0 до 3.0.0, но НЕ включая 3.0.0. По моему опыту, плагин пакета Maven всегда будет записывать диапазон, где min - это ваша версия пакета зависимостей maven, а max - следующая major версия.

Изменение импорта вручную:

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

.
0 голосов
/ 28 июня 2018

Этот импорт основан на скомпилированном коде. Там нет никаких неприятных маленьких лакомых кусочков, которые могут приставать к вам. Их цель - убедиться, что то, с чем вы работаете, совместимо с тем, с чем вы скомпилировали. Я предполагаю, что среда выполнения имеет более низкую версию, чем вам требуется. Это означает, что ваш путь компиляции в Maven имеет более поздние версии, чем ваша среда выполнения. Если бы вы могли запустить свой код, вы, скорее всего, столкнулись бы с ошибками Class Not Found Exception или No Such Method.

А может и нет. Но тогда вы можете столкнуться с худшей ситуацией, когда что-то не так (обещания, сделанные во время компиляции, могут быть не выполнены), и проблемы могут возникнуть намного позже после нанесения ущерба.

Этот материал есть по очень веской причине. Они похожи на заземление на вилках, они защищают вас.

Как это исправить? Посмотрите на ваши зависимости. Вы должны убедиться, что вы компилируете против версии, которая ниже или равна той, которая присутствует в вашей среде выполнения. Сначала вы можете посмотреть версии в вашем POM. Если этих версий нет, посмотрите на путь компиляции, используемый Maven.

Замена чисел в манифесте - это все равно, что спилить заземляющий контакт на вилке, потому что в противном случае он не поместится в стене ... плохая идея.

...