采用OSGi框架开发项目的十个问题

OSGi是Java领域里无可辩驳的最成熟的模块系统，它与Java几乎是如影相随，最早出现于JSR 8，但是最新规范是JSR 291。OSGi在JAR的MANIFEST.MF文件中定义了额外的元数据，用来指明每个包所要求的依赖。这就让模块能够（在运行时）检查其依赖是否满足要求， 另外，可以让每个模块有自己的私有 classpath（因为每个模块都有一个ClassLoader）。这可以让dependency hell尽早被发现，但是不能完全避免。 　　不过，Java社区领袖Adam Bien最近在其博客中认为，从技术角度讲，OSGi的确是实现模块化的可行办法，但OSGi的主要挑战不是技术，而是模块和bundle的管理。他建议在决定采用OSGi框架开发项目之前，考虑以下问题： 针对模块（bundle），采取何种版本 控制方案？大、小版本如何定义？ 采用何种软件配置管理策略？允许开放和维 护模块所有版本的分支吗？预计要维护多少个分支？通过SVN吗？ 在生产环境中，同时存在多少不同版本的模块？ 针对模块和模块组合，如何进行测试？每一个版本都会显著增加复杂度。 采用何种发布管理策略？提供客户专属的模 块组合吗？缺陷修补/补丁策略是什么？ 需要在系统运行中替换模块吗？如何处理正 在进行的事务？ 对于Eclipse RCP应用，是否应该开放插件给最终用户？ 采用何种软件分发系统？很多公司已经有了一套软件分发系统。应用和JVM经常打包到一个二进制文件中整体安装。增量更新几乎是不可能的。 模块之间如何交互？只通过Java接口吗？如果是，那么JPA实体的直接关联如何处理？ 是否采用Maven描述模块和 OSGi？Maven模块版本会在OSGi bundle版本中得到体现吗？ 　　Adam Bien认为，在深入思考这十个问题之后，OSGi可能就不再是项目的最佳选择。 　　读者朋友是否同意Adam Bien的观点，针对他的十个问题，有何看法？在实际开发中又是如何解决的？欢迎踊跃发表意见。