如果您考虑一下，尝试处理包的远程导入/导出是非常复杂、脆弱且容易出错的；您需要通过网络发送所有捆绑生命周期事件，并在导入系统中兑现它们（这需要缓存）。
此外，框架需要提前知道使用这些类定义（您不能实例化引用类加载器不可用的类的类）。一个远程包的类加载器可能依赖于另一个类加载器的类，这个链可能会在网络中循环，使得类加载需要很长时间。
换一种方式; 如果没有它们所依赖的类定义，您的本地捆绑包将永远无法解决，并且考虑到网络/硬件上可能有数千个潜在的远程导出器具有非常差的 SLA，考虑到分布式计算的谬误，这将无法很好地扩展或非常健壮.
如果我们尝试做远程包，框架需要从所有可用的远程节点导入所有导出的包，然后只选择一个来导入每个包导出（这是任意的，如果选择节点关闭，整个导入远程包过程将不得不再次触发）。
您需要做的是将您的 api/接口与您的实现分开，然后将 api 包分发到需要它的所有节点，然后使用 dOSGi 导入服务。
抱歉，如果这不清楚或胡说八道，但它应该解释为什么远程导出包根本不切实际。
附带说明；我不确定 r-osgi 是否正在积极维护或与最新的远程服务管理规范保持同步，从查看对 SVN 中继的最后一次提交是 2011 年 2 月 14 日。这里列出了一些替代的 dOSGi 实现（但避免使用 CXF）。
编辑：在部署方面，可以从 OBR 分发包（和配置）（有许多公共包和几个实现Felix / Eclipse），或者可以使用pax url handler重新分配 maven 存储库。