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

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

• 在导入库或导入捆绑包时手动指定指令 sharing:=clone
• 当作用域应用程序由于使用约束冲突而无法解析时自动触发。

从那时起，代码得到了一些整理，为 Spring 框架的常见克隆情况添加了一个主要的性能优化，添加了日志消息以指示哪些捆绑包已被克隆，改进了跟踪，并修复了一些错误。

我们注意到，手动克隆是一个相对安全的操作，因为它完全在用户的控制之下。但是，自动克隆始终是推测性的。它由 OSGi 解析器故障驱动，特别是使用约束冲突（如早期博客中所述）。一些使用约束冲突无法通过克隆避免，但我们无法在尝试自动克隆并仍然存在使用冲突之前知道这一点。这可能涉及运行解析器和克隆一个或多个捆绑包的多个迭代。有时，特别是如果克隆 Spring 框架捆绑包，还需要克隆 Spring DM 扩展器捆绑包和一些关联的机制。

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

在接下来的几个冲刺中，dm Server 团队的目标是发布 M3。在此之前，我们希望您提供关于社区（即您）希望为此配置选项设置什么默认值的反馈。您希望默认情况下启用还是禁用自动克隆？

默认情况下启用它的好处是，自动克隆支持将趋于获得更多使用，并且任何剩余的错误都更有可能被发现。默认情况下禁用它的好处是，除非用户选择加入，否则用户不会接触到自动克隆的相对复杂性和可能的性能成本。我更倾向于默认启用它，至少在开发的这个阶段是这样，但我还没有决定在最终发布 2.0 时默认值应该是什么。

在 M3 之后，克隆支持将重构到新的部署程序架构中，但更多内容将在其他场合介绍。