Избегать дублирования импорта OSGi в зависимости от maven? - PullRequest
Новая
       12

Избегать дублирования импорта OSGi в зависимости от maven?

5 голосов
/ 21 июня 2011

В настоящее время, когда я пишу пакет, который зависит от пакета, мне приходится «импортировать» или «зависеть» от целого другого пакета в Maven, который содержит этот пакет.

Похоже, этоконтрпродуктивно тому, что дает мне OSGi.

Например, скажем, у меня есть два пакета: BundleAPI и BundleImpl.

BundleAPI предоставляет интерфейсы API: 

// BundleAPI's manifest
export-package: com.service.api

BundleImplобеспечивает реализацию: 

//BundleImpl's manifest
import-package com.service.api

Однако, когда я кодирую BundleImpl в Eclipse, я вынужден "зависеть" в maven POM от BundleAPI - такна это затмение не жалуется. 

//BundleImpl's POM
<dependency>
    <groupId>com.service</groupId>
    <artifactId>com.service.api</artifactId>
    [...]
</dependency>

Итак - с одной стороны, я зависел только от пакета com.service.api , а с другой- Мне нужен весь пакет - BundleAPI .

Есть ли способ сделать maven или Eclipse достаточно умными, чтобы просто найти пакеты где-нибудь, вместо целых пакетов?

Я очень смущен тем, как это работает - любойТип ясности здесь был бы великолепен.Может быть, мне не хватает чего-то принципиально простого?

Ответы [ 3 ]

7 голосов
/ 21 июня 2011

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

Во время сборки вы должны зависеть от всего артефакта, то есть файла или пакета JAR.Это в значительной степени неизбежно из-за того, как работают компиляторы Java.Однако во время выполнения вы зависите только от пакетов, которые вы используете в своем пакете, и именно так OSGi управляет заменой во время выполнения.Это оператор Import-Package в вашем последнем пакете.

Конечно, как разработчик, вы не хотите перечислять два параллельных набора зависимостей, это было бы сумасшествием.К счастью, maven-bundle-plugin основан на инструменте bnd, который вычисляет инструкцию Import-Package для вас на основе анализа вашего кода и обнаружения фактических используемых пакетов.Другие инструменты, такие как bndtools (основанная на Eclipse IDE для разработки OSGi), также используют bnd таким образом.Между прочим, bnd гораздо надежнее и точнее, чем кто-либо другой, выполняет эту работу!

Итак, вы определяете только те зависимости уровня модуля, которые вам нужны во время сборки, и инструмент генерирует зависимости уровня пакета во время выполнения.

Я бы рекомендовал не использовать Tycho, потому что это заставляет вас использовать Eclipse PDE, что, в свою очередь, заставляет вас вручную управлять импортированными пакетами (ради полного раскрытия я являюсь автором bndtools, который конкурирует с PDE).

4 голосов
/ 21 июня 2011

Вы не можете разрабатывать пакеты, как обычные проекты Java с Maven и eclipse.В основном у вас есть 2 варианта.

  • Apache Felix Bundle Plugin : По сути, вы разрабатываете проект как обычный Java-проект и используете Maven как обычно.Этот плагин будет использоваться для добавления всех особенностей OSGi в манифест jar во время развертывания, чтобы OSGi включил его.Недостатком этого подхода является то, что вы используете проект Java в своем рабочем пространстве вместо пакета, что делает выполнение вашего проекта в контейнере OSGi немного дополнительной работой, поскольку Eclipse не распознает его как проект плагина.Таким образом, вы должны добавить банку из сборки Maven как часть целевой платформы вручную.
  • Tycho : Это еще один плагин Maven, который пытается фактически объединить эти две среды вместе и выполняетдовольно хорошая работа этого.В этом сценарии вы фактически создаете проект пакета / плагина Eclipse, который, очевидно, обеспечивает бесшовную интеграцию в Eclipse.Затем pom помечает проект как тип eclipse-plugin, который эффективно заставляет Maven разрешать зависимости проекта (определенные в манифесте) через целевую платформу вместо самого Maven.

Я бы взялПодход Tycho, поскольку он дает гораздо более комплексный подход с Eclipse.

0 голосов
/ 07 июля 2011

Наличие всей фляги как зависимости не должно быть проблемой, так или иначе вы должны делать это с Maven.

...