複製功能是 dm Server 2.0 中的一項特色，可將特定的套件 (bundles) 和程式庫複製到作用域應用程式（即 PAR 或作用域計畫），如藍圖中所述。

dm Server 中對複製功能的支援在過去幾個衝刺週期中穩步發展。基本機制已在 M1 中到位：複製可以被觸發

• 透過在 import-library 或 import-bundle 指令中指定 sharing:=clone 來手動觸發
• 當作用域應用程式由於 uses 限制衝突而無法解析時自動觸發。

從那時起，程式碼經過了一些整理，針對 Spring Framework 被複製的常見情況添加了主要的效能最佳化，添加了日誌訊息以指示哪些套件已被複製，追蹤功能得到了改進，並且修復了一些錯誤。

我們注意到手動複製是一個相對安全的操作，因為它完全在用戶的控制之下。然而，自動複製始終是推測性的。它是由 OSGi 解析器故障驅動的，特別是 uses 限制的違規（如先前的部落格中所述）。有些 uses 限制違規無法透過複製來避免，但在嘗試自動複製且 uses 違規仍然存在之前，我們無法判斷。這可能涉及多次迭代執行解析器和複製一個或多個套件。有時，特別是如果複製了 Spring Framework 套件，則也必須複製 Spring DM 擴充器套件和一些相關的機制。

所有這些處理在最壞的情況下可能需要幾秒甚至幾分鐘。因此，我們正在添加一個配置選項，以允許關閉自動複製。此選項的一個用途是在啟用自動複製的情況下開發應用程式。如果自動複製對於解析應用程式是必要的，但效能是不可接受的，則可以使用手動複製（並且可以禁用自動複製）。

在接下來的幾個衝刺週期中，dm Server 團隊的目標是發布 M3。在此之前，我們希望社群（即您）能針對此配置選項的首選預設值提供回饋。您希望預設情況下啟用還是禁用自動複製？

預設情況下啟用的好處是，自動複製支援將傾向於獲得更多使用，並且任何剩餘的錯誤都更有可能被充分發掘出來。預設情況下禁用的好處是，用戶將不會接觸到自動複製的相對複雜性和可能的效能成本，除非他們選擇加入。我個人傾向於預設啟用它，至少在開發的這個階段是這樣，但我尚未決定最終發布 2.0 時的預設值應該是什麼。

在 M3 之後，複製支援將被重構到新的部署器架構中，但更多相關資訊將在另一個場合介紹。