balancer 捆绑包的声明导出和单元测试要求的最佳方法是什么？
考虑要为其编写单元测试的捆绑“mybundle” . 捆绑包的源存储在IDE的“项目”概念中 . 例如：
mybundle
src/java
mybundle.package1
...java
bnd.bnd
单元测试我指的是单个POJO的测试，与更广泛的OSGi上下文无关，在这些上下文中可以在一个包中使用这些类 . 在可能的情况下，测试应该可以通过'vanilla'类加载运行，例如Eclipse中的JUnit运行程序 .
在开发时，这里有几种打包单元测试的方法：
捆绑源中的单元测试
在这里，单元测试被添加到项目的源文件夹中：
mybundle
src/java
mybundle.package1
...java
test/java
mybundle.package1.test
...java
bnd.bnd
请注意附加的'.test'以区分包并避免拆分包问题 .
通常会有一些措施来确保测试类不会在构建的bundle JAR中结束 .
在单独的捆绑中进行单元测试
这里添加了一个单独的包，名称后缀为' . test'，这是一般约定 .
mybundle
src/java
mybundle.package1
...java
mybundle.test
test/java
mybundle.package1.test
...java
bnd.bnd
这样做的问题在于，因为类是分开的，并且单元测试的运行可能不了解OSGi环境（例如使用Eclipse JUnit运行器），所以必须装饰JUnit运行器的运行时类路径 .
片段中的单元测试
（谢谢@HollyCummins） . 这里创建了一个单独的bundle片段：
mybundle.fragment
test/java
mybundle.package1.test
...java
bnd.bnd
该片段将'mybundle'声明为其主机，从而允许它在'mybundle'中共享类，而无需导出包 .
这样做的缺点是因为片段加载是OSGi概念，所以需要使用OSGi容器运行或装饰类路径 .
出口问题
在考虑bundle如何执行Export-Package时会出现问题 . It is considered good practice to export as few packages as possible . 然而，单元测试似乎迫使额外的包出口 .
对于第二个选项，这是最明显的，具有单独的测试包 . 测试包中的测试必须对正在测试的类进行Import-Package，并且测试中的bundle还必须Export-Package所有正在测试的所述类 .
因此，显而易见的解决方案是倾向于在捆绑源中进行单元测试，但问题很快就会出现在非平凡的情况下 . 您可能希望共享测试代码，例如，您可能在单独的捆绑包中进行OSGi集成测试 . 要共享代码，您最终必须导出 - 打包测试包，然后您最终也会在构建的包中测试代码！
What is the best way to organise OSGi bundles/projects for testing?
2 回答
第三种选择是使用OSGi片段进行单元测试 . 这可以确保您的测试与要测试的代码共享一个类加载器，因此不需要额外的软件包导出内部软件包 . 如果需要，测试片段甚至可以导出主包的内部包 . 该片段将具有自己的包导入，因此它可以引入共享的测试代码而不会污染主包的包导入 .
正如上面的评论中提到的和更新的原始问题一样，使用片段仍然会让您对如何处理构建和类路径留下一些疑问 . 如果您在OSGi容器外运行测试，那么片段的类加载器优势很可能会消失，除非您在IDE中引入导入的测试依赖项 .
如果你're running your tests in an OSGi container, fragments do have some disadvantages compared to normal bundles which may be a problem, depending how you'重新开车测试 . 碎片可以具有独立的生命周期 . 尽管Blueprint服务通常是can，但声明式服务也无法以自然方式从片段中注册 .
使用Maven会使选项1的实现变得非常简单 . 优点是Maven manages your classpaths适合您，因此任何仅需要进行测试的代码或依赖项都不会最终出现在最终的包中 . 您甚至可以将单元测试放在与测试类相同的包中，这样您就可以从测试中访问包私有类 . 由于使用正常的类加载执行测试，
Export-Packages根本不会影响它 .