高效的OSGi开发工作流程

Question

高效的OSGi开发工作流程

15

我在一款产品上工作，该产品由许多捆绑包组成，作为karaf顶部的功能运行。通常我们的开发人员一次只处理一个捆绑包。我们的正常开发流程大致是这样的：编写代码，编译，将捆绑包复制到部署文件夹中，进行测试。我们还发现，在不重启服务器或者卸载/重新安装某些已安装的功能之前，热部署会拒绝覆盖特定的捆绑包，因此有时候这个周期会更长。

我的问题是：社区里有没有更好的方法？我们做事情的方式虽然可行，但我觉得它相当缓慢和低效，我敢打赌有人想到了更好的方法！

编辑：我意识到我的问题表述不太清楚......我们在Karaf底层使用Equinox。我们还使用Eclipse和Maven，尽管我不知道使用Maven是否相关。

- Jon7

我目前正在测试这些答案。它们都非常棒，我想在接受其中一个之前看看哪个最适合我。 - Jon7

1

抱歉让您等待那么久！我尝试了所有的答案，最喜欢的是 dev：watch。它只需要最少量的工作（这意味着人们实际上会使用它），并且它能够满足我们的需求。最终，我不认为我希望eclipse每次保存时都重新编译和部署...我想说，大约95％的时间我保存时，我的代码不能正常工作。可以说，我很享受编译并看到新编译的bundle自动运行在我的服务器上的感觉！ :) - Jon7

1

我同意。这也是我采用的方法，但使用的是IDEA。它还鼓励我使我的捆绑包含更少的服务，这样它们就不需要花费太长时间来重新加载。这也是检查您的捆绑包之间是否存在加载顺序依赖关系的好方法！ - Chris Dolan

4个回答

3

如果您使用Eclipse，那么Eclipse Libra可能会对您有用。Libra可以像任何其他服务器一样在Eclipse中启动Felix、Equinox和Knopflerfish，并且具有一些如何使用它的YouTube视频。

我还编写了一些工具，可以帮助您：

- 一个OSGI bundle，可以捕获与过滤器匹配的OSGI服务（osgitest=junit4）。通过这个bundle，您不需要编写JUnit类，但可以提供预配置的对象（例如，使用OSGI Blueprint）。JUnit基于接口提供的注释运行。 - 一个Maven插件，具有以下有用的目标： - 启动OSGI容器并部署bundle Maven项目及其所有依赖项（当然是OSGI bundles）。启动OSGI容器是通过PAX Exam的帮助完成的，但是JUnit测试是通过我编写的OSGI bundle（运行您可能提供的OSGI服务）完成的。 - 创建一个包含指向项目所有依赖项的快捷方式的文件夹（位于Maven存储库或文件夹的目标目录中）

如果将项目部署到服务器（Eclipse Libra），则只需更新X，其中X是bundle的ID，所有内容都会迅速刷新。如果在Libra中运行Equinox，则无需重新编译发布到服务器的项目，因为它指向刷新的目标类文件夹，只要保存类或pom.xml，它就会自动刷新。

如果不将项目发布到服务器，而是将其作为bundle添加到容器中并指向快捷方式文件夹，则在运行mvn install后，也可以在OSGi控制台上运行更新命令（无需重新启动服务器）。

有一个详细的指南可在http://cookbook.everit.org/找到。

通过以上方法，您可以编写TDD测试，并将它们作为Maven编译的一部分在CI服务器上运行。

希望您会像我一样发现这些工具非常有用！

- Balazs Zsoldos

3

我在Eclipse中使用Equinox获得了出色的结果-即使热代码替换也可以正常工作。尽管目标平台很小，我们只有大约50个自己的bundle，但工作流程如下：首先，我们有一个目标平台，其中包含所有第三方和Eclipse bundle，Eclipse负责下载和管理它们。然后，工作区具有项目的所有bundle，分为3-4个工作集。编译通常在保存时发生，有时需要重新编译GWT，但即使如此，更改也会立即被捕捉到，因为不需要部署-运行的Equinox系统使用未打包的项目文件夹作为bundle。从Eclipse中运行这个系统可以给我们提供热代码替换，在飞行中更改模板文件，只有MANIFEST.MF/plugin.xml更改需要刷新bundle-即使这样，重启框架通常比在控制台中输入更快。

- Tassos Bassoukos

这个问题是关于Karaf+Maven而不是Equinox/P2/Eclipse插件的。 - earcam

2

这取决于Karaf下的平台：Felix或Equinox。

Equinox

Eclipse对于启动Equinox并选择要使用的捆绑包有出色（或几乎出色）的支持。您需要准备的两件事情是：

1.正在开发的捆绑包，作为插件项目在工作区中可用 2.目标平台，其中包含应用程序的其余捆绑包

这样的设置将允许您轻松地更改捆绑包，甚至在运行时轻松重新启动运行时，如果需要的话。我认为当您在远程系统上开发时，Karaf更适合，在这种情况下，捆绑包通过SSH或FTP部署，或者当您使用外部构建工具（如Maven）时，具有自动复制捆绑包的能力在构建后运行时。

如果您使用Equinox，则会比Felix多一些优势，因为运行时将直接从工作区执行代码。

Felix

Felix似乎没有像Eclipse一样的启动支持（虽然有一个跟踪在这个Jira问题中）。您也可以像普通Java应用程序一样启动它，但这远非方便。在这种情况下，使用Maven将是更好的选择。您仍然可以设置Eclipse以充分利用PDE的其他功能，只是启动将在外部完成。

总之，您始终可以通过Maven自动化所有操作，并且Karaf将在这方面极大地帮助您。如果您使用Equinox，Eclipse将给您略微优势。无论使用哪种方法，您都应该能够进行热代码替换，因为热代码替换根本不考虑OSGi（除了唯一的情况，即重新加载捆绑包并创建新的类加载器）。

- Danail Nachev

1

这并不完全正确 - 1）启动Karaf并不等同于启动Karaf包装的Equinox / Felix框架（Karaf添加了大量功能），2）使用Eclipse的Maven插件将在Karaf配置为使用Equinox / Felix时工作 - 在这种情况下使用Equinox没有任何优势。 - earcam

这取决于您使用Karaf的目的以及是否需要此额外功能。如果您剔除Karaf添加的这些功能，那么如果您正在使用Equinox，您将获得更好的与Eclipse集成。对于Felix来说，不会有太大变化。
我的意思不是说当您拥有基于Maven工作流程和Equinox时，Eclipse可以帮助您，而是如果平台是Equinox，基于Eclipse的工作流程将比基于Maven的工作流程更好，因为Felix在Eclipse中不是那么完全集成。

- Danail Nachev

我并不是在抨击你，只是想就Karaf进行澄清。 - earcam

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- earcam · Accepted Answer

听起来你需要使用dev:watch命令。文档中写到：

watch命令可以帮助开发过程中，它允许你配置一组要监视的URL。所有与给定URL匹配的bundle位置将自动更新。这避免了手动更新bundle或者复制bundle到系统文件夹的需要。请注意，只有基于maven的url和maven快照才会自动更新，所以如果你运行

dev:watch *

实际上它会监视所有具有匹配mvn:*的位置，并且在它们的url中包含“-SNAPSHOT”的bundle。

在Karaf shell中执行"dev:watch --help"可以列出其可用的标志和参数。

类似的工具是PAX插件

如果你已经安装了Eclipse的m2 maven插件，那么这两个工具都可以很好地工作。

更新：在我们公司，我们尽可能地遵循TDD原则，因此很多开发工作都是在没有显式启动Karaf的情况下完成的。在正常的单元测试中，我们还使用Pax Exam，即使在Eclipse中运行时也非常棒 =）

这有助于确保我们不会太依赖于任何Karaf特定的内容，因为它可以与Equinox/Felix/Concierge一起运行（所以我模拟了我们依赖的各种Karaf特定内容，比如JAAS身份验证）。除了许多其他很酷的工具/功能外，它还能够提供Karaf功能并使用TinyBundles，你甚至可以即时创建bundle（对于模拟/存根非常有用）。

Pax Exam通过提供JUnit @Runner来连接到JUnit框架，最新版本（2）速度更快，并且具有基于DSL的API，因此测试非常简洁易读。

使用Pax Exam可以为我们提供良好的测试覆盖率和较短的开发时间。当测试不太实用或者我们正在寻找不在测试中出现的错误时，dev:watch命令是非常有价值的。

总之，我认为你应该使用测试驱动的开发方法（Pax Exam可以很好地融入你现有的构建中，一旦你习惯了它，你会发现开发速度更快）。你可以立即开始使用dev:watch命令，它肯定会加速你的当前情况。

更新2: 在回答另一个问题时，我添加了一个使用Maven的示例，Pax-Exam测试了一个ComponentFactory。测试驱动开发可以说是当前对开发人员最有效的工作流程。问题链接：osgi: Using ServiceFactories?，源代码链接: http://dl.dropbox.com/u/2465717/net.earcam.example.servicecomponent_2011-08-16_15-52.tgz。