什么是合理的OSGi开发流程？

Question

我正在工作的最新项目中使用OSGi，就模块化和功能性而言，它非常漂亮。

但我对开发流程不满意。最终，我计划有30-50个不同的包，按依赖关系图排列--据推测，这就是OSGi设计的目的。但我无法找到一种干净的方法来管理编译时的依赖关系。

示例:您有bundle A和B。B取决于在A中定义的包，每个包都是作为一个单独的Java项目开发的。

为了编译B，A必须在javac类路径上。

你是否：

1. 参考B的构建脚本中项目A的文件系统位置？
2. 构建A并将jar扔到B的lib目录中？
3. 依赖Eclipse的“引用项目”特性，并始终使用Eclipse的类路径来构建(ugh)
4. 为所有项目使用一个通用的"lib“目录，编译后在那里转储包jars？
5. 设置一个包存储库，解析构建脚本中的清单并从存储库中解压所需的包？

5号听起来是最干净的，但也像很多的开销。

Answer 1

基本上，您可以使用：

• 源依赖项(使用Eclipse的“引用项目”)
• 二进制依赖关系(使用包A的jar )

但是，由于二进制依赖要干净得多，所以它也是最好的依赖类型，最好由像maven这样的发行版管理框架来管理。

您可以通过m2eclipse将maven集成到您的Eclipse项目中。

然后使用的Maven插件是：maven-bundle插件，您可以在其中看到：

• 使用maven创建osgi包(osgi felix示例)
• Maven的捆绑插件
• 在其他项目类型中获得maven-bundle插件的好处
• 如何使用Maven捆绑插件构建OSGi包

考虑一下这个使用Felix的Log实现的更真实的例子。 日志服务项目由一个包组成：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>

Answer 2

我的公司有100+包项目，我们使用Eclipse来管理依赖关系。但是，我不建议使用“必需的插件”方法来管理依赖项。你最好的选择是创建插件项目。仅从要显示的每个项目导出包。然后在进口端执行以下操作：

打开报表编辑器

左下角的依赖项选项卡是一个名为“依赖项的自动管理”的部分。

添加当前插件所依赖的任何插件。

一旦编写了代码，就可以单击该选项卡上的“添加依赖项”链接来自动计算导入的包。

如果从Eclipse运行，则在执行时会自动为您完成此操作。

这种方法的好处是您构建的包只使用OSGi定义的包导入/导出机制，而不是使用来自Eclipse的包。

如果你想了解更多，我建议去这个网站订购这本书。太棒了。

http://equinoxosgi.org/

Answer 3

好吧，做以前应该做的事，分开实现和API .好的，在现有的系统上，这并不总是那么容易，但是这个模型对你的成本有很大的帮助。一旦您的API位于一个单独的(更稳定的) bundle/jar中，您就可以针对该bundle/jar编译客户机和实现。

成功捆绑的关键之一是尽可能少地假设外部世界。这意味着您不必针对在运行时运行的包进行编译，我倾向于尽量不这样做。您应该只针对包的最小依赖集进行编译。如果假设是明确的，它们就是导入的包和服务的使用。设计良好的OSGi系统试图为所有包间通信使用服务。这个模型不仅消除了类加载问题，还使您的构建设置更加解耦。

不幸的是，大多数代码都是作为具有相当宽的接口的库编写的，因为它们传递了大量服务提供的功能，比如工厂和监听器。这段代码在实现和API之间有着紧密的关系，所以在编译期间和在OSGi中，您必须在类路径上有相同的关系。解决此问题的一个解决方案是在使用它的包中包含此类代码(但要确保此库的对象不会泄漏到其他包中)。有点额外的内存消耗，但它可以让你免于头痛。

因此，使用OSGi，尝试创建依赖于服务的系统，并根据其服务API进行编译，而不是一个实现包。