包含OSGi捆绑包的其他资源
我正在开发一个OSGi包，它实现了一个服务作为本机可执行文件的包装器。 也就是说，该服务使用ProcessBuilder运行可执行文件，为其提供一些数据，并检索结果。 我的问题是打包这个包的最佳方法。 本机可执行文件包括许多依赖数据文件，这些文件必须全部存在于磁盘上才能运行该工具。 我发现有很多关于在OSGi中处理本机DLL的引用，但是没有一个引用与必须存在于磁盘上的bundle相关联的文件，而不是只能通过类路径检索。
我想我可以直接在bundle archive中包含exectuable和dependent文件，然后在bundle启动时以编程方式提取到某个目录。 我能想到的另一个选择是将可执行文件放在某处并设置指向它的系统属性，但我希望将配置保持在最低限度。
一个不是特定于特定OSGi实现的解决方案会很好，但如果没有，我会使用Equinox。
谢谢！
这些附加文件是否需要由本机代码写入？ 如果没有，没有什么能阻止你把任何你喜欢的文件放在一个包里。
你在OSGi中遇到的常见问题是计算出文件的路径，因为OSGi并不认为文件系统是可用的（它不像OSGi在嵌入式设备中启动时那么奇怪）。
如何控制本机代码查找其相关文件的位置？ 你需要传递一条路吗？
如果你想要一个目录来复制或解压缩东西，那么使用：
org.eclipse.core.runtime.Platform.getStateLocation()
它为您提供了捆绑包的工作目录。
如果要查找捆绑中特定文件的路径，可以执行以下操作：
org.eclipse.core.runtime.FileLocator.toFileURL((context.getBundle().getEntry("/etc/readme.txt")))
在这种情况下，将返回当前包中的/etc/readme.txt的文件URL。
这两段代码都假设它们位于激活器的start()方法中。
当然，您的解决方案是有效的。 但是，您必须小心停止并删除在安装期间提取和启动的任何资源。 如果可执行文件还创建了任何类型的工作文件，则可能特别难以跟踪。
您应该这样做是因为OSGi的优势之一是生命周期管理，它允许您无需跟踪即可删除捆绑包和服务。 为此，框架跟踪捆绑包的所有内容。 如果在删除已安装并启动它的软件包后保持可执行运行，则连接将丢失，并且可能会继续运行，直到重新启动计算机（通常不是嵌入式系统的选项）。