最近幾天和幾周，我們看到人們對由 OSGi 捆綁包組成的應用程式構建解決方案的未來越來越感興趣。由於我們與 OSGi 的密切關係，這在我們心中佔有重要地位，我們花了很長時間研究客戶需求和這些需求的解決方案。在這篇部落格文章中，我將概述我們已經確定的需求，並提出我們認為可以滿足這些需求的解決方案。

我非常樂意傾聽那些有額外要求、認為我們現有要求不合理或對解決方案有更好想法的人。

OSGi 構建要求

無重複的依賴元資料

當前 OSGi 構建的一個實際問題是依賴元資料可能在許多地方重複。對於 dm Server，我們在 ivy.xml、.classpath 和 MANIFEST.MF 檔案中描述了依賴項。任何 OSGi 構建的長期解決方案都必須只要求一個位置來儲存依賴元資料。

與現有構建解決方案配合使用

鑑於 OSGi 應用程式的獨特性，嘗試從頭開始構建系統是很有誘惑力的。我們曾一度考慮過這個想法，但後來發現這在技術上不可行，也不是我們使用者的最佳解決方案。

我們的使用者對他們選擇的構建解決方案投入了大量精力，讓他們遷移似乎不是務實的方法。相反，使用者希望有一個能夠很好地融入他們的 Maven 或 Ant 構建的解決方案。

自動生成清單檔案

遷移到 OSGi 最簡單的方法可能是根據應用程式模組可用的相關元資料自動生成清單檔案。理想情況下，這種方法將使應用程式程式碼或開發人員使用該程式碼的方式發生最小的變化。

從 OSGi 清單中獲取構建依賴項

儘管清單生成是一種有效的方法，但許多使用者對將其 OSGi 清單視為依賴元資料的規範描述很感興趣。這些使用者希望根據他們在清單中編寫的元資料來驅動他們的構建。為了支援輕鬆建立清單，許多使用者希望看到對清單模板的支援。清單模板允許自動生成樣板清單內容，同時讓使用者完全控制版本等重要資訊。

這種方法將清單用作 IDE 和離線構建中的核心依賴描述符。開發人員手動編寫 OSGi 清單，或者在工具的幫助下編寫，構建工具以類似於 Maven 使用 pom.xml 和 Ivy 使用 ivy.xml 的方式使用清單。

使用 OSGi 元資料進行解析允許在構建期間應用完整的 OSGi 解析規則集。這將允許構建時依賴解析與執行時發生的解析更準確地匹配。

這種方法的一個潛在缺點是開發人員需要在他們的清單中指定測試依賴項。Maven 和 Ivy 都有標記僅用於測試環境的依賴項的方法，在使用清單進行依賴解析時也需要類似的解決方案。

場景

根據這些要求，我們推匯出了四個主要場景。有趣的是，這些場景中的每一個都由我經常為 dm Server 互動的一個或多個使用者代表。

1. Maven 和 Eclipse - pom.xml 驅動

與下一個場景一樣，這是我們遇到的最頻繁的場景，也是我們目前花費最多時間工作的場景。透過這種方法，開發人員像對待任何正常的 Maven/Eclipse 專案一樣執行他們的開發任務。

OSGi 清單檔案由 Maven 和 Eclipse 外掛生成。開發人員可以選擇讓 Eclipse 外掛作為增量構建的一部分或按需重新生成清單。

生成 OSGi 清單所需的大部分元資料可以在 Java 程式碼（原始碼/位元組碼）中找到。但是，無法從位元組碼中推匯出合理的依賴項版本號。在這種情況下，版本可以從 pom.xml 檔案或可自定義的清單模板中提取。

清單模板可以承載比版本號更多的資訊，允許開發人員新增 OSGi 屬性和指令以及任何自定義頭。

2. Ant、Ivy 和 Eclipse - ivy.xml 驅動

此方法類似於 Maven 的 pom 驅動方法，只是依賴元資料將從 ivy.xml 檔案而不是 pom.xml 檔案中提取。

開發人員將可以使用 Ant 任務在構建的適當階段執行清單生成。

這種方法最大的缺點是 Eclipse 中缺乏引人注目的 Ivy 整合。對於 Ivy 2，Eclipse 外掛支援可悲地缺乏。我們正在考慮的一種方法是從生成的清單建立 Eclipse 類路徑。這是我們已經支援並將在接下來的兩個場景中擴充套件的工具。開發人員將編寫 ivy.xml 檔案，使用 Eclipse 外掛生成他們的清單，並自動更新 Eclipse 類路徑。

3. Maven 和 Eclipse - MANIFEST.MF 驅動

在此方法中，OSGi 清單檔案是專案依賴元資料的明確宣告。開發人員可以選擇手動編寫整個清單，但最有可能的是他們將編寫清單模板並讓我們的外掛完成其餘工作。

dm Server 工具已經附帶了一個由清單驅動的 Eclipse 類路徑容器，它將擴充套件以支援準確的傳遞依賴解析。

為了支援在此環境中的測試，外掛將允許編寫 MANIFEST.MF 和 TEST.MF 檔案，其中 TEST.MF 描述僅適用於測試的依賴項，而 MANIFEST.MF 描述在測試和生產期間都適用的依賴項。

此場景的最後一部分是如何與 Maven 銜接。我們目前正在研究兩種方法：替換/整合 Maven 依賴解析器或生成 pom.xml 檔案。我很想聽聽您對哪種方法最有價值、對您最有益的意見。

4. Ant、Ivy 和 Eclipse - MANIFEST.MF 驅動

此方法與以清單驅動方式使用 Maven 非常相似。與場景 2 不同，此場景不受缺乏良好 Ivy/Eclipse 整合的影響，因為我們將使用與場景 3 中相同的清單驅動 Eclipse 類路徑容器。

OSGi 構建工具

為了滿足概述的要求，我們正在構建一套與 Maven、Ant 和 Ivy 協同工作的工具，以提供用於構建 OSGi 應用程式的整合解決方案。

Bundlor

Bundlor 是我們內部使用了一段時間的工具，用於生成 OSGi 清單。我們主要用它來建立您在我們企業捆綁包倉庫中看到的所有捆綁包。Bundlor 可用於為在建立時未過多考慮 OSGi 的遺留庫生成清單。Bundlor 也可用於為專門針對 OSGi 建立的捆綁包生成清單。Bundlor 減輕了建立高質量捆綁包清單的大部分繁重工作。

Bundlor 支援清單模板的概念，允許您自定義生成的清單。使用模板，您可以向包匯入和匯出新增版本和屬性，從匯出中排除包，在無法自動檢測時新增匯入，以及新增額外的清單頭。下面的程式碼片段顯示了我們一個示例應用程式的清單。

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: GreenPages Service
Bundle-SymbolicName: greenpages
Bundle-Vendor: SpringSource Inc.
Bundle-Version: 1.0
Import-Template: org.springframework.*;version="[2.5.6.A,3.0)"
Excluded-Exports: greenpages.internal

在此示例中，Excluded-Exports 頭用於防止 greenpages.internal 被暴露。Import-Template 頭用於為所有與 org.springframework.* 模式匹配的包名設定版本。專案程式碼被掃描以確定可能的匯入和匯出集。然後使用模板檔案來控制此集中的哪些匯入/匯出實際進入清單以及它們具有哪些版本。重要的是，生成過程將為您正確生成使用元資料，消除了最繁瑣的工作之一。

Bundlor 實際上將支援建立兩個清單檔案：MANIFEST.MF 和 TEST.MF。TEST.MF 檔案將用於描述僅在測試期間需要的依賴項。這對於希望使用清單驅動構建但又不想用測試依賴項汙染生產清單的開發人員很重要。

在接下來的幾周內，我們將釋出 Bundlor 的第一個公開里程碑。在此版本中，您將能夠從 Ant 和 Maven 中為專案生成清單，並且能夠使用清單模板自定義這些清單。在此之後的幾個里程碑中，我們將新增對從 pom.xml 和 ivy.xml 檔案自動檢測依賴項版本的支援。

我們將在 Bundlor 1.0 最終版釋出時將我們的大部分示例從手寫清單切換為使用 Bundlor 和清單模板。此外，我們還將把 dm Server 遷移到 Bundlor，放棄所有手寫清單。

BundlorEclipse

BundlorEclipse 是一個 Eclipse 外掛，它使 Bundlor 功能直接在您的 Eclipse IDE 中可用。使用此外掛，您可以將完全增量清單生成作為正常的 Eclipse 構建生命週期的一部分執行。如果像我一樣，您對儲存按鈕有點過於隨意，您可以將 BundlorEclipse 配置為僅按需生成清單。

當將其與即將推出的 dm Server 容器內測試框架結合使用時，您將能夠從 Eclipse 內部啟動完整的 dm Server 測試環境，包括所有捆綁包的清單檔案。

離線依賴解析器

OSGi 有自己的一套規則，用於解析模組之間的依賴關係，以及如何驗證這些依賴關係並將其轉換為一致的類空間。在 OSGi 之外，構建工具在平面類路徑上工作，該類路徑列出了要搜尋類的 JAR 和目錄。

為了支援清單驅動的構建，我們將建立一個離線依賴解析器，該解析器無需啟動 Equinox 或 dm Server 即可執行 OSGi 解析。我們將把它與一個工具配對，該工具將 OSGi 解析圖扁平化為用於編譯和測試的簡單類路徑。此扁平化過程將由使用者完全可配置，使用者將能夠提供策略資訊來管理 OSGi 圖中的多個版本如何對映到類路徑中的單個版本。

清單類路徑容器

使用依賴解析器，我們將能夠改進我們的清單類路徑容器，為每個 Eclipse 專案建立一個完整的、傳遞的類路徑。

Maven/Ivy 依賴解析器/pom.xml/ivy.xml 生成器

依賴解析器也將構成我們的依賴解析器/pom.xml/ivy.xml 生成器工具的核心部分。這裡的關鍵觀察結果是，作為開發人員，您應該期望在 Eclipse 和構建工具中獲得一致的結果。

為什麼是 Bundlor 而不是 Bnd？

您可能知道，OSGi 技術總監 Peter Kriens 提供了一個名為 bnd 的工具，其用途與 Bundlor 類似。我們最初的立場是在我們自己的專案中使用 bnd，並將其作為我們工具的一部分。事實上，在 Bundlor 出現之前，Spring Dynamic Modules 就一直在使用 bnd 來建立其捆綁包。那麼，我們為什麼決定建立 Bundlor 呢？

建立 Bundlor 的主要原因是，我們必須支援 bnd 中不存在的一些附加功能，例如：

• 基於 JDT 的原始碼掃描
• 部分程式碼處理
• 增量清單建立

這些功能用於支援 BundlorEclipse。我們在 Eclipse 中使用基於 JDT 的掃描代替位元組碼掃描，以改善使用者體驗並更好地整合到 Eclipse 構建生命週期中。Eclipse 能夠很好地處理部分正確的程式碼，我們希望 Bundlor 能夠以同樣的方式支援部分程式碼。

在 BundlorEclipse 中，可以將 Bundlor 配置為每次在 IDE 中儲存更改時執行。為了使其高效，我們支援增量清單生成。當您對程式碼進行更改時，Bundlor 可以跟蹤需要對清單檔案進行哪些更改，並避免重新建立所有清單。

使用 Eclipse 以外的 IDE

我們知道，儘管 Eclipse 是 Java 開發人員的主導 IDE，但仍有大量開發人員使用 IntelliJ 和 NetBeans 等 IDE。

雖然我們不會承諾為這些 IDE 構建任何外掛，但我們將把所有描述的工具作為開源提供，使其他人能夠為他們喜歡的 IDE 建立外掛。

我們構建工具的方法是嘗試將盡可能多的功能封裝在通用庫中。我們致力於與 NetBeans 和 IntelliJ 團隊合作，幫助他們將我們的工具庫整合到他們的 IDE 中。

理想的最終結果是，無論您使用什麼 IDE，您仍然可以訪問相同的底層 OSGi 工具。

進一步的要求

OSGi 構建的要求並不僅限於我概述的 4 個場景。還有許多功能和增強功能可以改善開發人員使用 OSGi 應用程式的體驗。

批次捆綁包生成

許多商店將有大量非 OSGi 捆綁包的 JAR 工件積壓。我們計劃擴充套件 Bundlor 以支援批次捆綁包生成。在此模式下，您將能夠透過將 Bundlor 指向 JAR 目錄並讓 Bundlor 為所有這些 JAR 建立捆綁包來節省時間。此外，Bundlor 將能夠利用這些工件之間的關係來確定依賴項的版本範圍應該是什麼。這將減少您必須編寫的模板程式碼量，同時仍能生成高質量的捆綁包。

儲存庫驅動的程式碼完成

使用清單驅動構建構建 dm Server 應用程式時，您必須手動編寫初始清單匯入。藉助儲存庫驅動的程式碼完成支援，您將能夠針對 dm Server 儲存庫獲得 Eclipse 程式碼完成，這將生成 Java 匯入和清單匯入。使用此功能，您將能夠根據需要構建清單依賴項，而無需切換到清單檔案。