克隆是dm Server 2.0中的一个功能，它将某些捆绑包和库复制到限定范围的应用程序（即PAR或限定范围的计划）中，如路线图中所述。

在过去的几个冲刺中，dm Server对克隆的支持稳步发展。基本机制已在M1中到位：克隆可以通过以下方式触发

• 通过在import-library或import-bundle上指定指令sharing:=clone手动触发
• 当限定范围的应用程序因用途约束冲突而无法解析时自动触发。

此后，代码经过了一些整理，针对Spring框架被克隆的常见情况添加了主要的性能优化，添加了日志消息以指示哪些捆绑包已被克隆，改进了跟踪，并修复了一些错误。

我们注意到，手动克隆是相对安全的操作，因为它完全在用户的控制之下。然而，自动克隆总是推测性的。它是由OSGi解析器故障驱动的，特别是违反了“uses”约束（正如之前一篇博客所解释的）。有些“uses”约束违规是无法通过克隆来避免的，但我们直到尝试了自动克隆并且“uses”违规仍然存在时才能知道。这可能涉及运行解析器和克隆一个或多个bundle的多次迭代。有时，特别是当Spring框架bundle被克隆时，还需要克隆Spring DM扩展器bundle和一些相关的机制。

所有这些处理，在最坏的情况下，可能需要几秒甚至几分钟。因此，我们正在添加一个配置选项，允许关闭自动克隆。这个选项的一个用途是开发一个启用了自动克隆的应用程序。如果自动克隆对于解析应用程序是必要的，但性能无法接受，那么可以使用手动克隆（并且可以禁用自动克隆）。

在接下来的几个冲刺中，dm Server团队的目标是发布M3。在此之前，我们希望得到社区（即你们）对这个配置选项的默认值的偏好反馈。您希望自动克隆默认启用还是禁用？

默认启用的好处是，自动克隆支持将倾向于得到更多的使用，并且任何剩余的bug更有可能被发现。默认禁用的好处是，用户不会接触到自动克隆的相对复杂性以及可能的性能成本，除非他们选择启用。我个人倾向于默认启用它，至少在开发的这个阶段是这样，但我尚未决定当我们最终发布2.0时默认值应该是什么。

M3之后，克隆支持将被重构到新的部署器架构中，但更多内容将在以后讨论。