Вопросы Теги

Что такое разумный рабочий процесс разработки OSGi?

Я использую OSGi для своего последнего проекта на работе, и это довольно красиво до модульного принципа и функциональности.

Но я не доволен рабочим процессом разработки. В конечном счете я планирую иметь 30-50 отдельных пакетов, расположенных в графе зависимостей - предположительно, это - то, для чего разработан OSGi. Но я не могу выяснить очевидный способ для управления зависимостями во время компиляции.

Пример: у Вас есть пакеты A и B. B зависит от пакетов, определенных в A. Каждом пакете разрабатывается как отдельный проект Java.

Для компиляции B A должен быть на javac пути к классу.

Сделайте Вас:

  1. Сослаться на местоположение файловой системы проекта A в сценарии сборки B?
  2. Создать A и бросить банку в каталог lib B?
  3. Полагайтесь на функцию "ссылочных проектов" Eclipse и всегда используйте путь к классу Eclipse для создания (тьфу)
  4. Используйте общий каталог "lib" для всех проектов и выведите банки пакета там после компиляции?
  5. Откройте репозиторий пакета, проанализируйте декларацию из сценария сборки и выпадающий необходимые пакеты из репозитория?

№ 5 звучит как самое чистое, но также и как много издержек.

7
задан levand 4 May 2010 в 20:53
поделиться

4 ответа

В принципе, вы можете использовать:

  • исходную зависимость (с помощью "referenced projects" Eclipse)
  • бинарную зависимость (используя jar пакета A)

Но поскольку бинарная зависимость намного чище, она также является тем типом зависимости, который лучше всего управляется системой управления релизами, такой как maven.
И вы можете интегрировать maven в свой проект Eclipse через m2eclipse.

Плагин Maven, который нужно использовать, будет таким: maven-bundle-plugin, который вы можете увидеть в действии в:

Рассмотрим этот более реальный пример с использованием реализации Log Service от Felix.
Проект Log Service состоит из одного пакета: org.apache.felix.log.impl.
Он имеет зависимость от основных интерфейсов OSGi, а также зависимость от интерфейсов сборника OSGi для конкретных интерфейсов службы журнала. Ниже приведен его POM-файл:

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.felix</groupId>
  <artifactId>org.apache.felix.log</artifactId>
  <packaging>bundle</packaging>
  <name>Apache Felix Log Service</name>
  <version>0.8.0-SNAPSHOT</version>
  <description>
    This bundle provides an implementation of the OSGi R4 Log service.
  </description>
  <dependencies>
    <dependency>
      <groupId>${pom.groupId}</groupId>
      <artifactId>org.osgi.core</artifactId>
      <version>0.8.0-incubator</version>
    </dependency>
    <dependency>
      <groupId>${pom.groupId}</groupId>
      <artifactId>org.osgi.compendium</artifactId>
      <version>0.9.0-incubator-SNAPSHOT</version>
    </dependency>
  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.felix</groupId>
        <artifactId>maven-bundle-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <instructions>
            <Export-Package>org.osgi.service.log</Export-Package>
            <Private-Package>org.apache.felix.log.impl</Private-Package>
            <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
            <Bundle-Activator>${pom.artifactId}.impl.Activator</Bundle-Activator>
            <Export-Service>org.osgi.service.log.LogService,org.osgi.service.log.LogReaderService</Export-Service>
          </instructions>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>
2
ответ дан 6 December 2019 в 12:47
поделиться

В моей компании 100+ проектов, и мы используем Eclipse для управления зависимостями. Однако я не рекомендую использовать подход "Требуемые плагины" для управления зависимостями. Лучше всего создавать проекты плагинов. Экспортируйте только те пакеты из каждого проекта, которые вы хотите видеть. Затем на стороне импорта сделайте следующее:

Откройте редактор Manifest

Перейдите на вкладку зависимостей В левом нижнем углу есть раздел "Автоматизированное управление зависимостями"

Добавьте туда все плагины, от которых зависит текущий плагин

После написания кода вы можете нажать ссылку "добавить зависимости" на этой вкладке для автоматического расчета импортируемых пакетов.

Если вы работаете из Eclipse, это будет сделано автоматически при выполнении.

Преимущества такого подхода в том, что ваши собранные пакеты используют только определенный OSGi механизм импорта/экспорта пакетов, а не что-то из Eclipse.

Если вы хотите узнать больше, я рекомендую зайти на этот сайт и заказать книгу. Она превосходна.

http://equinoxosgi.org/

7
ответ дан 6 December 2019 в 12:47
поделиться

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

Одним из ключевых качеств успешного пакета является то, что он делает как можно меньше предположений о внешнем мире. Это означает, что вам не нужно компилировать пакеты, с которыми вы работаете во время выполнения, я предпочитаю очень стараться этого не делать. Вы должны компилировать только минимальный набор зависимостей пакетов.Если предположения сделаны, то они явно выражаются как импортированные пакеты и использование сервисов. Хорошо спроектированные системы OSGi пытаются использовать сервисы для всей связи между пакетами. Эта модель не только избавляется от проблем с загрузкой классов, но и делает настройку сборки более независимой.

К сожалению, большая часть кода написана в виде библиотек с довольно широким интерфейсом, поскольку они передают в код множество функций, которые сервисы предоставляют из коробки, например, фабрики и слушатели. Этот код имеет тесную взаимосвязь между реализацией и API, поэтому вы должны иметь то же самое в пути к классу во время компиляции и в OSGi. Одним из решений этой проблемы является включение такого кода в пакет, использующий его (но убедитесь, что никакие объекты этой библиотеки не попадают в другие пакеты). Небольшое дополнительное потребление памяти, но это избавляет вас от некоторых головных болей.

Итак, с OSGi попробуйте создавать системы, полагающиеся на сервисы, и компилировать их с API сервисов, а не с пакетом реализации.

5
ответ дан 6 December 2019 в 12:47
поделиться

Есть 6-й вариант, который я использовал для нескольких проектов, который заключается в том, чтобы использовать один проект Eclipse (не проект плагина, а просто обычный Java-проект) и поместить туда весь исходный код. Файл сборки, связанный с проектом, просто скомпилирует весь код за один проход и впоследствии создаст пакеты из скомпилированных классов (используя Bnd из Ant или из скоро выпущенного BndTools).

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

2
ответ дан 6 December 2019 в 12:47
поделиться
Другие вопросы по тегам:

Похожие вопросы: