克隆是 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 之後，克隆支援將被重構到新的部署器架構中，但更多內容將在其他場合討論。