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

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

• 通过在 import-library 或 import-bundle 上指定指令 sharing:=clone 来手动触发
• 当作用域应用程序由于 uses 约束冲突而无法解析时自动触发。

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

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

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

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

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

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