我有一个基于 OSGi 的服务器端应用程序，它使用文件系统来存储脚本和配置数据。
随着时间的推移，我想将该应用程序移至“云”，这将无法很好地处理它当前对文件系统访问的依赖。
我想做的是在这个应用程序中插入一个 JCR 层，所以它仍然可以在当前情况下工作（本地文件系统上的常规文件），但会为云情况铺平道路。
我确实在 modeshape 中找到了一个文件连接器，但是我遇到了与 OSGi 非常严重的不兼容问题，该问题尚未得到修复。此外，ModeShape 引入了很多依赖项（我认为大约 6 MB），这对我来说是个问题。
因此，除了开始破解我自己的 JCR 实现之外，我看不到任何选择，而我不愿意这样做。
有任何想法吗？
尽管您不会直接使用 JCR，但使用 Apache Sling ResourceProvider 机制应该可以让您在以后轻松地从文件系统迁移到其他系统，并且它对 OSGi 友好，因为 Sling 100% 基于 OSGi。
您现在可以使用 Sling 的文件系统资源提供程序 ( http://sling.apache.org/site/accessing-filesystem-resources-extensionsfsresource.html ) 开始，然后根据需要移至您自己的自定义 ResourceProvider。
文件系统提供程序的源代码位于https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/fsresource - 这是非常简单的代码，可以用作创建自己的 ResourceProvider 的示例。
对于您的自定义系统，问题是您需要多少 Sling 捆绑包才能使其正常工作 - 我不知道在我的脑海中，但建议使用 Sling Launchpad 来找出答案，它会启动一个带有很多的香草 Sling 系统您不需要的捆绑包，但您可以尝试将其减少到仍然允许 ResourceProvider 机制工作的最低限度。
您还可以使用 Apache Commons VFS2，例如 JCR 连接器，或者您可以使用 webdav 或 JDBC 表。我在共享 JDBC 表顶部的原子（类 git）树顶部的商业项目中使用它。