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