Cloudinary-libs доступны как артефакты Maven. Такие JAR-файлы могут быть помещены в ваш пакет как частные библиотеки с помощью maven-bundle-plugin .
. Следующий пример работает для меня (даже с тестовой учетной записью Cloudinary)
...
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<executions>
<execution>
<!-- Create the bundle late in the compile-phase instead of the package-phase.
So the generated OSGi meta-data is available during JUnit tests. -->
<id>run-before-tests</id>
<phase>process-classes</phase>
<goals>
<goal>bundle</goal>
</goals>
</execution>
</executions>
<configuration>
<instructions>
<Bundle-Name>Test Bundle</Bundle-Name>
<Embed-Dependency>*;groupId=com.cloudinary;scope=compile|runtime</Embed-Dependency>
<Embed-Directory>OSGI-INF/lib</Embed-Directory> <!-- not needed, but nice -->
<Embed-Transitive>true</Embed-Transitive>
</instructions>
</configuration>
</plugin>
...
<dependencies>
<dependency>
<groupId>com.cloudinary</groupId>
<artifactId>cloudinary-core</artifactId>
<version>1.24.0</version>
</dependency>
<dependency>
<groupId>com.cloudinary</groupId>
<artifactId>cloudinary-http44</artifactId>
<version>1.24.0</version>
</dependency>
...
В общем случае встраивание внешней библиотеки может быть от простого, громоздкого до невозможного. Это зависит от зависимостей импортированных артефактов.
Проверьте дерево зависимостей вручную! (например, https://mvnrepository.com/)
Вы должны поиграть с 3 инструкциями:
Embed-Dependency
Это библиотеки, которые поставляются в вашем комплекте. Будьте осторожны с оператором звездочки, иначе вы можете включить слишком много зависимостей (в случае AEM - просто половина целого числа rnet). Но не включайте тоже меньше! Извлеките встроенный bundle.jar, чтобы увидеть, что на самом деле включено (в случае облачного хранилища это было легко).
Import-Package
Часто у библиотек тоже есть путь много зависимостей, особенно если библиотеки приходят в другую экосистему (например, контейнеры Spring или JEE) или имеют много необязательных зависимостей. С помощью этого параметра вы можете указать OSGi, что пакет можно активировать, даже если некоторые зависимости недоступны.
Это пример из реальной жизни:
<Import-Package>
!com.sun.msv.*,
!org.apache.log4j.jmx.*,
!sun.misc.*,
!org.jboss.logging.*,
!org.apache.zookeeper.*,
*
</Import-Package>
Export- Пакет
Обычно библиотека должна быть частной. Но иногда приходится импортировать по-другому, или библиотека делает что-то автоматически. Поэтому вы всегда должны проверять в системной консоли, что экспортирует ваш пакет. В случае, если это неверно, вы должны вручную поиграть с этим параметром:
Вот пример:
<Export-Package>
!*.internal,
!*.internal.*,
!*.impl,
!*.impl.*,
com.mycompany.myproject.mybundle.*
</Export-Package>
По умолчанию все пакеты * экспортируются, кроме именованных impl или internal. Также их дочерние пакеты являются частными (правило !*.impl.*). Если значение по умолчанию не работает, экспортируйте с этой инструкцией только то, что вам нужно.
Все, что вы экспортируете, отправляется в глобальное пространство OSGi. Так как комплекты AEM и Sling-Bund не идеальны и не на 100% без ошибок, пожалуйста, убедитесь, что
- порядок запуска / выключения готовых комплектов AEM не должен изменяться
- развертывание, повторное развертывание или развертывание вашего кода не должно запускать / останавливать какие-либо готовые пакеты AEM.
Если вы этого не гарантируете Вы можете столкнуться со странными проблемами развертывания, которые очень трудно найти / решить.
Так что лучше всего НЕ экспортировать что-либо, импортированное каким-либо готовым комплектом AEM. Все остальное только для экспертов. И даже они переоценивают себя и недооценивают долгосрочные затраты на исправление AEM вручную.
PS: инструкция _removeheaders может удалить все osgi-инструкции, которые не нужны для выполнения. Но делайте это только в том случае, если вы хотите предоставить пакет для публикации c и сделать его полностью блестящим. Я бы оставил это как документацию.