SpringSource Application Platform 的主要優勢之一是其按需供應依賴項的能力。這有兩個好處：它確保平臺記憶體佔用儘可能小，並且允許應用程式在不將所有依賴項封裝在單一部署單元（例如 WAR 檔案）中的情況下進行部署。要利用這些功能，您需要了解平臺的供應儲存庫，而這篇博文將提供這些資訊。

供應儲存庫在哪裡？它是如何工作的？

預設情況下，平臺的供應儲存庫位於安裝根目錄下的 repository 目錄中： 如您所見，有三個主要目錄：bundles、installed 和 libraries。installed 用於平臺內部使用，所以我們將重點關注 bundles 和 libraries 目錄。每個目錄包含多個子目錄，用於分隔不同型別的依賴項。

• ext 包含平臺提供的外部依賴項，但它們本身並非平臺的一部分。
• subsystems 包含構成平臺的所有子系統。
• usr 最初為空，用於包含使用者新增的依賴項，即您的應用程式依賴但平臺尚未提供的任何內容。

平臺在啟動時搜尋 repository 目錄結構中的捆綁包和庫。我將在本文後面討論如何配置此搜尋。當在儲存庫中找到捆綁包和庫時，它們的符號名稱、匯出包等詳細資訊將被新增到儲存庫的記憶體索引中。掃描完成後，記憶體索引將被快取到磁碟。在開發過程中，最小化平臺的啟動時間是我們的一個重點。這種快取允許平臺在啟動時節省一些時間：除非檢測到儲存庫內容已更改，否則它可以跳過掃描。

執行時供應

在純粹的 OSGi 環境中，捆綁包的依賴項只能由已安裝在環境中的其他捆綁包來滿足。例如，安裝和啟動一個匯入 org.apache.commons.dbcp 包的捆綁包，如果還沒有任何匯出該包的捆綁包被安裝，將會失敗。這對於使用者來說可能非常麻煩，因為他們必須手動安裝捆綁包的所有依賴項。幸運的是，SpringSource Application Platform 透過按需動態安裝依賴項，大大改進了這一點。

當平臺啟動已部署的應用程式時，其捆綁包將被安裝到 Equinox 中。然後，平臺會向 Equinox 請求一個包含所有捆綁包未滿足依賴項的列表，並嘗試滿足它們。讓我們透過一個簡單的場景來分析這個過程。

1. 一個匯入了 org.apache.commons.dbcp 的捆綁包由平臺安裝到 Equinox 中。
2. 平臺向 Equinox 請求該捆綁包的未滿足依賴項，並被告知對 org.apache.commons.dbcp 的匯入無法滿足。
3. 平臺在其供應儲存庫的索引中搜索匯出 org.apache.commons.dbcp 的捆綁包。
4. 平臺將匯出 org.apache.commons.dbcp 的捆綁包安裝到 Equinox 中。
5. 在滿足了原始捆綁包的依賴項後，平臺成功啟動了該原始捆綁包。

我們希望這將極大地簡化使用者的生活：只要您的應用程式的依賴項對平臺可用，您就可以簡單地部署您的應用程式並開始使用！無需再耗費時間和精力手動安裝應用程式的所有依賴項。這個過程的一個優點是依賴項僅在需要時安裝。您可以將任意數量的捆綁包新增到供應儲存庫，而幾乎不會對平臺的記憶體佔用產生影響。

如果平臺無法從其儲存庫中滿足某個依賴項，則會生成一條日誌訊息，詳細說明無法滿足的依賴項。有了這些資訊，您可以使用 SpringSource Enterprise Bundle Repository 來獲取所需內容。我們希望該儲存庫提供儘可能完整的捆綁包集：如果您需要某個依賴項而它不可用，請 告知我們。

向供應儲存庫新增條目

所以，您已經下載了一兩個依賴項，現在想將它們新增到平臺。您只需將它們複製到儲存庫中的相應目錄即可。例如，一個新的捆綁包通常會被新增到 repository/bundles/usr 目錄，而一個新的庫描述符通常會被新增到 repository/libraries/usr 目錄。

如上所述，平臺使用一個記憶體中的供應儲存庫索引，該索引在啟動時被填充。此外，平臺在每次部署應用程式時還會檢查其儲存庫檢視是否最新。當您想安裝帶有新依賴項的應用程式時，只需將依賴項複製到儲存庫中的相應位置，然後部署您的應用程式。在部署處理過程中，平臺會注意到儲存庫已更新，並會重新整理其檢視。這意味著您無需花費時間重新啟動平臺即可安裝帶有新依賴項的應用程式。

跨安裝共享供應儲存庫

平臺搜尋供應儲存庫中的條目的位置可以輕鬆配置以滿足您的需求。例如，多個平臺例項可以共享部分或全部供應儲存庫，這樣您就不必費力地在平臺安裝之間維護重複的捆綁包集。

平臺在建立其供應儲存庫時掃描的位置可以在 config/platform.config 檔案中進行配置。預設配置（在沒有特定配置的情況下使用）是：

"provisioning" : {
    "searchPaths": [ 
        "repository/bundles/subsystems/{name}/{bundle}.jar",
        "repository/bundles/ext/{bundle}",
        "repository/bundles/usr/{bundle}",
        "repository/libraries/ext/{library}",
        "repository/libraries/usr/{library}"
    ]
}

平臺將任何相對路徑解釋為相對於其安裝根目錄，並且也支援絕對路徑。花括號內的搜尋路徑中的條目只是萬用字元，例如，子系統搜尋路徑 repository/bundles/subsystems/{name}/{bundle}.jar 將在 subsystems 目錄的任何直接子目錄中找到以 .jar 結尾的任何檔案。

希望您能看到，共享部分或全部供應儲存庫在平臺之間是一個微不足道的更改。例如，要讓平臺在檔案系統的根目錄下的一個名為 shared-bundles 的目錄以及它自己的 subsystems 和 ext 目錄中進行搜尋，您只需將以下 JSON（JavaScript 物件表示法）片段新增到 platform.config 檔案中即可。

"provisioning" : {
    "searchPaths": [
        "repository/bundles/subsystems/{name}/{bundle}.jar",
        "repository/bundles/ext/{bundle}",
        "/shared-bundles/{bundle}",
        "repository/libraries/ext/{library}",
        "repository/libraries/usr/{library}"
    ]
}

透過使用此配置配置兩個或多個平臺例項，可以使它們共享 /shared-bundles 中的捆綁包。透過將所有搜尋路徑配置為指向共享位置，可以輕鬆地將此進一步發展，這樣您就不必管理每個平臺的供應儲存庫了。

下一步是什麼？

我們計劃透過提供一些工具或指令碼來簡化從同一組二進位制檔案執行多個平臺例項。這些工具或指令碼將為您完成大部分工作，提供一個合理的預設配置，然後您可以根據自己的具體需求進行調整。

我們還打算透過允許平臺配置為在嘗試滿足依賴項時選擇性地搜尋遠端儲存庫，來結合平臺按需供應和 SpringSource Enterprise Bundle Repository 的強大功能。如果在遠端儲存庫中找到依賴項，平臺將自動處理其下載和安裝。希望這將使開發者的生活變得輕鬆，尤其是在應用程式開發的早期階段，因為新依賴項會定期新增。

我們非常希望聽到您對我們正在開發的上述增強功能和平臺本身的建議：請隨時評論這篇博文、 提出 JIRA 或在我們的 論壇 上發帖。