幾周前，Spring Framework專案在其SourceForge主頁上的下載量突破了100萬次。真實的總數可能要高得多，因為這個數字不包括每日構建或Spring可以下載的其他站點。當然，Spring也被包含在大量且不斷增長的其他產品的發行版中。還有Spring.NET……

最重要的是，Spring持續發展勢頭：下載量增長非常迅速。Spring下載量最大的版本是最新生產版本1.2.8，下載量已達175,000次……

關於我最近關於 Spring 和 Maven 的宣告，已經有了相當多的討論。這些討論都非常好且有價值，但我確實想澄清我提出的一些觀點。

首先，我們致力於支援使用 Maven 作為首選構建系統的 Spring 使用者。這意味著我們將幫助確保從 Spring 2.0 RC4 開始的每個 Spring 版本在 Maven 倉庫中都有準確的 POM。這就是世界上最受歡迎的 JIRA 問題的全部意義。僅此而已。

Spring內部構建系統的話題是……

Spring Framework 2.0 RC4 已釋出。這是 Spring 2.0 最終版本之前的最後一個候選釋出版，您可以從釋出公告本身以及JIRA 問題列表瞭解有關此版本的更多資訊，以獲取此版本中更改的完整列表。

可能最重要的一點是，此版本為 2.0 DTD 和 Schema (XSD) 引入了帶版本的檔案/位置名稱。這是必要的，因為 2.0 的 XML Bean 定義格式得到了顯著增強，但 1.2.x 使用者仍然需要能夠引用 1.2.8 DTD。以下是使用 2.0“beans”schema 的示例（2.0 還附帶了許多其他新 schema，代表各種特殊名稱空間…

你猜是什麼？如果你猜是 Spring 的Maven bundle/build，你就贏了。12 月來Spring Experience找我，我們將分享一杯冰鎮飲料作為你的獎品。

我的過失

在我過去的職業生涯中，我做了很多配置管理和構建系統方面的工作。當我來到 Interface21 後，我立即自願盡我所能幫助構建基礎設施。接下來，我發現所有與 Maven 相關的票證，無論是 Spring 還是 Spring Web Flow，都被分配給了我。然後，由於我對 JIRA 的漫不經心，我讓這個問題發酵了。在過去的幾個月裡，關於 Spring 和 Maven 的事情確實一直在向前推進；我本應該在 JIRA 中釋出但卻沒有釋出的事情。這導致最近幾天在主要 JIRA 問題中出現了一些合理的抱怨。因此，為了讓大家瞭解最新情況，以下是當前的狀況。

狀態

對於過去幾個月對 Spring 2.0 和 Maven 感到絕望的人，你們不會再絕望太久了。Spring 社群已決定逐步將所有 Spring 專案轉換為 Maven。您可能知道Acegi 長期以來一直在使用 Maven。最近，Spring-WS 專案也進行了轉換。我個人已經原型化了Spring Web Flow的轉換，並且普遍認為 Spring 也將進行轉換。

話雖如此，現在還不是慶祝的時候。轉換最後兩個專案（Spring 和 Spring Web Flow）並非易事（如果您不相信我，只需看看《使用 Maven 構建更好的專案》）。因此，這種轉換並不是我們真的想在接近主要 2.0 和 1.0 版本釋出時做的事情。我能告訴您的是，轉換是一個計劃在釋出之後實現的目標。

那計劃是什麼？

其實很簡單。在接下來的幾周裡，我將為 Spring 和 Spring Web Flow 手動構建帶有依賴列表的 POM。目前，計劃是將這些 POM 與 Spring 和 Spring Web Flow 的最終版本一起釋出。釋出之後，在 Arjen 的幫助下，我將協助 Juergen 和 Keith 將他們的原始碼樹轉換為 Maven 構建，並讓這些構建在 Continuum 中執行。

那麼，我作為使用者，在此期間能做些什麼呢？

首先是要有耐心。我們在這個問題上沉默了這麼久是我的錯，希望這篇文章能為我們的思考過程提供一些透明度。其次，我很樂意提供測試幫助。我的計劃是在工作時將試用 POM 簽入 CVS 和 SVN，並在JIRA 問題上宣佈已進行更改。正如你所猜，手動建立 POM 容易出錯（這是推動 Maven 構建的驅動因素之一），所以我很樂意得到一些測試它們的幫助。在JIRA 中的評論，發帖到論壇，以及發帖到開發者郵件列表都是很好的反饋途徑。

還有其他你想知道的嗎？

再次，我希望這能緩解社群中的一些沮喪情緒，並讓您瞭解我們未來的方向。當然，歡迎對當前計劃提出任何意見（這裡的評論將是一個很好的地方），但我也想知道您是否有任何其他問題或讓您感到沮喪的問題。如果您在下面留下問題或直接給我傳送電子郵件，我將盡力給您一個滿意的答覆，並將其釋出到部落格上或透過電子郵件直接回復給您。

它始於一件小事。僅僅是我的一種直覺，認為 Spring 和 OSGi 應該很好地協同工作。這個想法是，透過使 Spring 應用程式能夠部署在 OSGi 執行時中，我們可以為 Spring 應用程式帶來更好的模組化、版本控制、執行時部署和更新功能。這是一個我從未真正宣傳過的專案；我只是開始實驗，與一些人交談，並編寫了一些早期的原型程式碼。

事實證明，很多人似乎對Spring和OSGi感興趣。我們正在與來自BEA、Oracle、IBM、Eclipse、OSGi聯盟以及其他幾家的代表進行合作，以建立一個關於Spring對OSGi支援應該是什麼樣子，以及如何使在OSGi執行時上構建企業應用程式變得容易的共享模型。最新版本的規範附在Spring JIRA問題1802中。這是規範文字的直接連結……

正如大家所知，Spring 2.0 的一大改進是增加了 AspectJ 切入點語言以及與 AspectJ 的更好整合。雖然我認為從長遠來看，這會帶來巨大的好處，但也導致了一些問題。我們發現 Spring AOP 始終具有某些 AspectJ 從未具有的行為。

出現的一個大問題是Before advice的行為。如果你在Spring 1.x中使用過Spring AOP，你可能知道Spring允許你在引數傳遞給目標之前更改其值……

Spring - 將長期存在 我每天都會拜訪許多客戶，並與更多客戶交談。這包括現有的 Interface21 客戶以及對我們在歐洲的產品和服務感興趣的公司。我注意到我正在進行的對話中有一個反覆出現的主題：Spring 在這裡，而且它將長期存在。

在過去的一年裡，我見證了高層決策，這些決策已將 Spring 標準化到領先的企業 Java 開發公司的整個結構中。就在兩週前，我問我的一位客戶——歐洲最大公司之一的 Java 部門經理……

最近我似乎一直專注於建立 Spring XML 名稱空間。在 XSD 和 Spring 兩方面，為了找到建立解析器的良好模式，經歷了大量的嘗試和錯誤。我遇到的最大困惑之一是 AbstractBeanDefinitionParser 層次結構。目前它的文件不是特別好（但有一個 JIRA 問題，所以會在 GA 之前修復），所以我將為您介紹您的選擇、它們的作用以及如何使用它們。

AbstractBeanDefinitionParser 的選擇

Spring 提供了三種主要的 BeanDefinitionParser 來幫助您解析 XML 名稱空間。

• AbstractBeanDefinitionParser
  • AbstractSingleBeanDefinitionParser
    • AbstractSimpleBeanDefinitionParser

我將從最具體的地方開始，逐步深入到最一般的地方，以展示在需要時如何獲得更大的能力。如果你想跳過示例並檢視摘要，請點選這裡……

大家好！

這是我上個月加入 Interface21 以來發布的第一篇文章。我之前的部落格現在已正式棄用，我將不再更新它。

那麼我第一篇文章的主題是什麼（除了自我介紹）？  驗證邏輯。  這不會是關於如何在 Spring 框架中執行驗證的演練，而是會討論我一個特別惱人的問題：)

特別是，我想討論驗證邏輯中應該包含哪些內容。  這似乎是一個無需思考的答案；“驗證指定資料的邏輯”。  好的，這確實是一個無需思考的答案，但請繼續閱讀 :)。如您所知，Spring 框架透過 Errors 和 Validator 介面為您的驗證提供了一個很好的抽象層。  特別是，Validator 是您將業務特定的驗證規則應用於填充的領域物件的地方。  Spring 出色的繫結支援負責更新您的領域模型…