Каков предполагаемый вариант использования Bundle-Classpath в пакетах OSGI

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

Возьмем пример. Предположим, что код в моем пакете использует библиотеку, например Google Guava. У меня есть два варианта упаковки моего набора:

1. Просто создайте мой пакет, в котором будет только мой собственный код. Пакет теперь будет иметь Import-Package операторы, которые объявляют зависимость от Guava, и любой, кто захочет развернуть мой пакет в своем приложении, также должен будет развернуть Guava.

2. В качестве альтернативы я могу включить копию Guava в свой комплект и ссылаться на нее из моего Bundle-ClassPath. Кто бы ни развернул мой пакет, он может развернуть только мой пакет, и ему не нужно беспокоиться о том, откуда взять Guava. Фактически, наличие Guava внутри моего пакета является деталью реализации, и разработчику даже не нужно знать, что я его использую.

Выбор между этими двумя вариантами - это компромисс. Вариант 2 имеет то преимущество, что мой пакет легче развернуть, потому что он автономный - все, что ему нужно, прямо внутри него. С другой стороны, мой пакет намного больше, чем должен быть, что может стать проблемой, если многие другие пакеты также будут встраивать свою собственную копию Guava.

Более серьезная проблема с вариантом 2 заключается в том, что все зависимости библиотеки теперь также становятся зависимостями мои. На самом деле Guava - это редкий пример библиотеки Java без собственных зависимостей ... но многие другие библиотеки Java тянутся в огромное дерево транзитивных зависимостей. Если вы используете этот подход, скажем, с Hibernate, тогда ваш собственный пакет также будет иметь этот большой набор зависимостей. Это становится очень уродливым, очень быстро.

Поэтому будьте осторожны, чтобы не злоупотреблять _4 _ / _ 5_. Вам следует подумать об использовании его только в том случае, если зависимость (а) мала и без транзитивных зависимостей, и (б) ваш пакет использует библиотеку в качестве внутренней детали реализации, то есть она не является частью вашего общедоступного API.

ОБНОВЛЕНИЕ

Я забыл ответить на ваш второй вопрос об экспорте. Ответ - НЕТ, экспорт любых «пакетов», которые вы помещаете на свой Bundle-ClassPath, НЕ будет экспортом вашего собственного пакета. Фактически, JAR, которые мы устанавливаем Bundle-ClassPath, вообще не рассматриваются как пакеты, это просто JAR.

Вы можете выбрать экспорт пакетов, которые поступают из JAR на вашем Bundle-ClassPath, но вы должны сделать это в MANIFEST.MF вашего собственного пакета.

Наиболее распространенный вариант использования этого заголовка - упаковка внешних библиотек. Допустим, у вас есть библиотека foo.jar, и вы хотите использовать ее классы в своем пакете.

Вы кладете банку в свой пучок вот так,

/
  com/company/Activator.class
  foo.jar
  META-INF/MANIFEST.MF

В вашем манифесте теперь вы можете использовать

Bundle-ClassPath: foo.jar,.

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

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

Я думаю, тебе здесь может быть не по себе.

Bundle-Classpath - это упорядоченный, разделенный запятыми список относительных местоположений JAR-файлов пакета, в которых выполняется поиск запросов классов и ресурсов.

Это означает, что когда некоторому классу пакета нужен другой класс в том же пакете, для поиска класса ищется весь путь класса пакета содержащего пакета.

Из OSGI в действии.

Рассмотрим конкретный случай. Представьте себе пакет (файл JAR) со следующей структурой:

src/a/A.class
src2/b/B.class
src3/c/C.class

если вы хотите, чтобы a.A, b.B и c.C были доступны друг другу, вам нужно будет определить src, src2 и src3 как относящиеся к пути к классам пакета. Это означает, что вам нужно добавить в свой файл манифеста следующую строку:

Bundle-ClassPath: src,src2,src3