在過去 5 年間出現的所有 Web 框架中,Jakarta Struts 是 Java? 開發人員使用得最多的一種框架,因此其后代的問世是一件值得注意的事情。雖然 Shale 還不是最流行的框架,也不是最為人熟悉的框架,但是出自名門的背景仍給人以深刻印象。更令人興奮的是,Shale 并不僅僅是 Struts 的重大升級和新的發行版:它徹底更新了 Struts 中的很多核心原則,并且加入了 Web 開發中最新的思想。
您將了解到,Shale 與 Struts 的背離是一柄雙刃劍。一方面,Shale 是經過精心設計的 Struts 的后代。Shale 的創立者綜合考慮了 Struts 的優點和不足,提出可與其前輩媲美的下一代框架。另一方面,正如您很快就可以在這個系列中看到的一樣,Shale 是 一種完全不同于 Struts 的框架,其中隱含著很多新的開發工作!
Shale 不僅僅是 Struts 的又一個修正版,它已擴展到超出 Struts 所能達到的高度。它包含 Java Web 程序設計中一些最重要的、最近的開發成果,包括 JSP Standard Tag Library(JSTL)和 JavaServer Faces(JSF),并建立在這些開發成果之上。Shale 完全應該被看作是與 Struts 不同的一種框架,在這個系列中,我將還 Shale 框架以本來面目。在這個月的文章中,將首先對 Shale 與 Struts 之間的區別作一個概述,然后帶您體驗安裝 Shale 并測試安裝情況的步驟。最后,我將給出一些思想,令您能進一步參與到 Shale 項目(它是開放源碼的)中,并提供一些相關的信息。整個系列的目的就是要向您展示如何安裝 Shale 以及如何使用 Shale 構建和開發項目,同時很少涉及 Shale 的前輩,即 Struts 框架。
評價 Shale
任何新的 Web 開發框架要想在這個競爭已經很激烈的領域占得一席之地,最好能夠經受住巨大壓力下的評測。好消息是,Shale 獨力經受住了細致的考察。但是,壞消息是,由于 Shale 完全是對 Struts 重新構建的產物,因此必須重新編寫和重新測試您所有基于 Struts 的代碼,以便實現這些代碼。您將花同樣多的精力來編寫一個新的 Shale 應用程序,或將一個 Struts 應用程序轉換成 Shale 應用程序,就好像 Shale 與 Struts 完全無關一樣。
所以接下來我們忍不住要問,為什么還要采用 Shale 呢?為了得出答案,我首先解釋一下 Shale 的偉大之處 —— 這在很大程度上是由于它的 Struts 血統,但這又不是惟一的原因 —— 然后討論 Shale 之所以沒有 被發布為 Struts 框架的重要修正版的兩大原因。這樣,您就會更好地理解從 Shale 身上可以得到什么,這將有助于評價使用這種下一代的框架是否值得。
Struts 血統
Shale 重用了大量的 Struts 代碼基,并聲稱 Struts 是它的 “父” 框架,因此如果您要相信 Shale 的價值,就得相信 Struts 的價值。首先,Struts 作為第一個真正意義上的 Web 開發框架,擁有巨大的價值。據 Shale 和 Struts 網站報道,第一批代碼是在 2000 年 6 月提交給 Struts CVS 存儲庫的,而Struts 1.0 是在 2001 年末才發布的。當很多開發人員正在艱難地使用 JavaServer Pages(JSP)和不斷變化的 servlet 規范時,Struts 提供了一種易于使用的 Model 2 方法來構建基于 servlet 和 JSP 的 Web 應用程序。換句話說,Struts 使 Web 開發人員可以開發健壯的 Web 應用程序,而不必精于日志記錄、分布式計算、JDBC、Servlet、JSP、JNDI、RMI 和 大量其他的 API 和技術。
接下來,Struts 要做的事情就是保持它的強大性:從寫出第一批代碼開始,Struts 連續 6 年一直是最流行的 Web 開發框架之一。至今它仍然是人們口中的談資,筆下的素材,使用得不比任何競爭對手少。由于 Struts 是如此流行,如此長壽,如今它已經有豐富的功能,有良好的文檔,被廣泛地支持,并且易于使用,在它上面進行開發和管理也很容易。數千名開發人員對 Struts 郵件列表上的問題作出答復,數萬名開發人員試用 Struts 并報告問題,這使得這些問題很容易得到修復。
最后,Struts 是不斷發展的。很多框架一開始比較強大,然后就停滯不前(商業產品和開放源碼項目都存在這樣的現象),而 Struts 總是不斷提供新的特性。當您下載 Struts 時,核心發行版中還包含一個健壯的確認引擎(validation engine),并且 Struts 已經與 JavaServer Faces 集成,擁有廣泛的標記庫和一個不斷發展的 Model 2 架構,其中引入了在分布式 n-層應用程序領域中最新的思想。而且告訴您,Struts 還緊跟程序設計中出現的新模式,例如 IoC(Inversion of Control)。Struts 與 WebWork 和 Spring 框架自然地集成,后兩者都是具有最佳血統的、為使用 Web 開發中的新方法提供入口的框架。
簡而言之,您很難發現在 Struts 中有做不成 或不支持的事。所以顯然我們就要問,為什么 Shale 要另起爐灶呢?為什么 Shale 沒有成為 Struts 的下一個版本呢?這有兩個主要原因:一個原因與鮮為人知的新軟件發行慣例有關,另一個原因則與眾所周知的 Struts 根基中的弱點有關。讓我們分別來考慮這兩個原因。
發行版辨析
要理解 Shale 為什么沒有成為 Struts 的一個新的發行版,首先需要理解關于新軟件發行的一兩件事。對于一個新的軟件發行版,大多數用戶首先看的是一組新的特性。版本升級的幅度越大,用戶對新特性的期待就越大。因此,如果軟件版本從 2.1 升級到 2.2,就應該有一些新的特性,但是如果從版本 2.2 升級到版本 3.0,那么就應該有很多 新特性。這就是為什么當一些大型產品(例如 Microsoft Word)或操作系統(例如 Windows 和 Mac OS X )出了新版本的時候,用戶總是對它們很挑剔。對于每一個新的發行版,用戶總是期待有更多新的特性。
由于大多數用戶一味地將注意力放在特性上,他們沒有意識到向后兼容性(backward compatibility)才是真正最有價值的東西。雖然每個人都希望 Excel 中加入新的、很好的選項,希望 Panther 與 iTunes 有更好的集成,希望 Gnome 中對 XUL 有更好的支持,但是如果那些用戶現有的程序和文件在新版本下突然不能運行的話,相信他們會尖叫,“這是血腥謀殺”。在這種情況下,新特性毫無價值。
對于 Struts 也一樣。一般來說,Struts 的每個新版本都增加了新的特性,同時保持了與之前版本的向后兼容性。此外,新版本的 Struts 還需要支持舊版本的 Java 平臺和 Servlet 規范,因為已安裝的舊的 Struts 要在這些平臺上運行。這兩個需求 —— 向后兼容性和對舊版本的 Java API 的支持 —— 對于 Shale 來說已經是一個嚴重的約束。尤其是,至少就 Java 平臺而言,JSF API 已經成為 Web 的中心組件。雖然 Struts 也支持 JSF,但是 Shale 卻是完全依賴于 JSF 的 —— 這對于需要維持向后兼容性的 Struts 來說簡直是不可能的。
最后,派生出一個像 Shale 這樣的新項目,同時繼續在 Struts 這種已有的項目上進行開發活動,這樣做具有無與倫比的優勢。如果 Struts 只是簡單地升級到 2.0(或者 3.0 或 4.0),并在不考慮向后兼容性的情況下實現 Shale,那么對于很多人來說,由此造成的移植工作將是令人痛苦的,可能有人干脆連 Struts 也不再使用了。即使仍然維護更舊的代碼基,也難于吸引開發人員花時間來修復 bug,他們也不愿意為一個 “遭到廢棄” 的或者 “舊” 版本的軟件增加特性。
由于這些原因,讓 Shale 成為一個全新的項目,使其建立在一個新的代碼基之上,是很有意義的。
Shale 的面向服務架構
Shale 之所以沒有成為 Struts 的一個新的發行版,其最后一個原因與邏輯沒有關系:而是與該框架將新方法接納到 Web 開發中的能力有關系。Shale 在很多方面與 Struts 存在不同之處,其中有兩點最為突出:
- Struts 與 JSF 集成,而 Shale 則是建立在 JSF 之上。
- Struts 實質上是一個巨大的、復雜的請求處理器;而 Shale 則是一組可以以任何方式進行組合的服務。
Shale 對 JSF 的依賴性具有深遠的、令人驚訝的意義,而且大部分情況下是積極的意義。隨著這個系列的深入,我將深入研究這些意義。在討論其他方面之前,有必要對造成 Shale 與 Struts 之間差異的第二個方面進行詳細的討論。
如果您多次使用過 Struts,那么會意識到它很大程度上可以看作一個請求處理器,通過它可以接受請求,并指示框架如何處理請求。您可以指出采取哪種動作,使用什么模型,將哪種視圖顯示給用戶,采用什么驗證規則,顯示哪種表單 ... Struts 是完全可以配置的。然而,所有這些的核心是一個請求處理器,為每個請求提供服務。這樣的處理器是 Struts 中最重要、也是最復雜的部分,因為對于在處理一個請求的過程中涉及的所有工作,它都必須進行處理或托管,在 Struts 代碼基中幾乎沒有哪一部分與這個請求處理器沒有關系或不受它的影響。
因此,Struts 基本上難于作出改變。如果想修改處理請求的方式,或改變處理請求過程中各部分的順序,那么將面臨巨大的困難。實際上,不得不重新編寫 Struts 代碼基。更改請求處理器的行為倒是稍微可行,但是大部分是不容變動的。這是 Shale 試圖解決的關鍵問題之一(如果您需要 Web 框架有那種程度的靈活性的話)。
Shale 沒有像 Struts 請求處理器那樣的中心組件,它只是一組數量很多的服務。可以自由組合這些服務,每個服務與其他服務之間是松散耦合的。通過一組良好定義的接口(有時候實際上就是 Java 接口類,有時候只是組件之間某種形式的契約),配置 Shale 的行為很容易。這使得 Shale 是可擴展的、靈活的,甚至是 “聰明的”。很容易更改它,不費吹灰之力就可以擴展它,并可以使它迅速適應新的編程方法。像這樣松散地組裝組件或服務通常被稱作面向服務的架構,或簡稱 SOA。當然,這聽起來有點兒玄乎,不過您大可不必因此而覺得 Shale 不好!
安裝 Shale
可以從邏輯上和概念上理解 Shale 與 Struts 的不同之處,但是要想在腦海里弄清楚這兩種偉大的框架有什么不同,則需要親自動手去實踐一番。很自然,每一種 Web 框架首先都需要下載和安裝。不過幸好,在這個過程中通常可以了解到很多東西。那些安裝和設置起來比較困難的項目和產品,通常也難于配置,難于在它上面進行部署,并且(最壞的情況)難于長久運行。雖然安裝過程很難作為評價一個 Web 框架好壞的最可靠手段,但是至少肯定應該成為這個標準的一部分。在這一節中,您將學習手動地安裝 Shale,對于一些難點有一定的體會,并了解為了使 Shale 運行,系統上需要些什么東西。
注意,我還提到了 Shale 的 簡便安裝 選項,但是我強烈建議您至少試一試手動安裝,了解它提供的較深層的信息。
先決條件
Shale 的先決條件和需求相當多。和大多數與 Apache 和 Jakarta 相關的項目一樣,Shale 的安裝要依賴于一些其他的 Jakarta 項目。下面是為了使 Shale 得以運行所需的所有東西的完整列表:
- Java Runtime Environment(JRE)和 Java Development Kit(JDK) 1.4 或更高版本
- Java Servlet API 2.4 或更高版本
- JSP 2.0 或更高版本
- JSF 1.1 或更高版本
- JSP Standard Tag Library(JSTL) 1.1 或更高版本
- Jakarta Commons BeanUtils 1.7 或更高版本
- Jakarta Commons Chain 1.0 或更高版本
- Jakarta Commons Digester 1.7 或更高版本
- Apache Logging 1.0.4 或更高版本
- Apache Ant 1.6.3 或更高版本
Apache Ant 只是在構建 Shale 時要用到,但是無論如何,如果您要進行較多的 Java 開發,那么系統上還是需要(很可能已經有了)一個版本的 Ant。如果想跟蹤 Shale 中的 bug,那么需要 FindBugs 0.8.5 或更高版本和 JUnit 3.8.1 或更高版本。由于在第 1 部分中我只是討論 Shale 的安裝和使用,因此您還不必關心 FindBugs 或 JUnit,除非您想早點兒裝上這兩個項目。
附件和它們的依賴項
和 Struts 一樣,Shale 還有一些附件(在 Shale 中常被稱作可選 Shale 組件),這些附件各自又有其依賴項:
- Jakarta Commons Validator 1.2 或更高版本
- Spring Framework 1.2.2 或更高版本
- Struts Tiles Framework(獨立版本)
如果說這份列表顯得有些長并且令人生畏的話,那么沒錯!Shale 使用大量較低級的庫、helper 類、實用程序組件和來自其他項目的類。如果必須逐個安裝這些組件,配置 Shale 使用它們,并將所有這些組件組裝成可以部署的某種形式的話,即使是最專業的開發人員也會對 Shale 望而生畏。此外,由于 Shale 在它的開發圈子內仍然相當年輕,對于這些依賴項的獲得和配置仍然有些稚嫩;然而,Shale 確實是非常可行的,而且不需要花費您想象中那么多的精力。
?
首先,如果您正在用某種框架從事某種 Web 開發,那么應該已經有了一些作為依賴項的項目。所以這份列表比它初看上去要容易管理得多。例如,任何 Web 開發人員都應該已經有 JRE 和 JDK,也應該有一個 servlet 引擎,例如 Jakarta Tomcat。如果已經有一個 servlet 引擎,那么也應該有 Servlet API 和 JSP 引擎。另外,大部分 servlet 引擎(至少就當前版本而言)都包括一個 JSTL,并且很多都附帶了 JSF。最后,大多數開發人員很可能在他們的機器上已經安裝了 Ant。因此,這份列表很快就只剩下這些了:
- JSF 1.1 或更高版本 (servlet 引擎中可能已經附帶了)
- JSTL 1.1 或更高版本 (servlet 引擎中可能已經附帶了)
- Jakarta Commons BeanUtils 1.7 或更高版本
- Jakarta Commons Chain 1.0 或更高版本
- Jakarta Commons Digester 1.7 或更高版本
- Apache Logging 1.0.4 或更高版本
考慮到 Tapestry 實際上提供了將它的所有依賴項附帶下載的選項,因此 “太多依賴項” 的問題很快就不成為問題了。
現在您已經知道了大概,現在我們來看看下載、安裝和配置 Shale 及其依賴項的步驟。
1. 下載 Shale
要下載 Shale,可訪問 Shale 項目主頁。您可以看到一個 “Shale Download” 區域,其中有 Shale 框架的每晚構建的鏈接。單擊這個鏈接,便可以進入如圖 1 所示的一個站點:
圖 1. 來自 Shale CVS 存儲庫的每晚構建
為了使 Shale 運行,需要下載 “framework” 文件和 “dependencies” 文件。例如,在撰寫本文時我下載了以下兩個文件:
- shale-framework-20060204.zip
- shale-dependencies-20060204.zip
當然,如果您需要或者更愿意下載 .tar.gz 版本,那么可以不選擇 .zip 版本,而選擇 .tar.gz 版本。由于 Shale 的開發還在進行中,目前還沒有發行的構建,因此您應該盡量下載最近的每晚構建(具有最近的日期)。
下載完這兩個文件后,首先解壓這兩個歸檔文件。對于核心框架,解壓后可以得到一個具有形如 shale-framework-20060204/ 的名稱的文件夾;對于 dependencies 歸檔文件,解壓后可以得到一個名為 lib/ 的文件夾。將核心框架目錄 shale-framework-20060204/ 轉移到您希望保存 Java 項目的地方。例如,在我的系統上,我將 shale-framework-20060204/ 移動到 /usr/local/java 目錄中。接下來,將 lib/ 目錄移動到 Shale 目錄中,所以最后的目錄結構與 shale-framework-20060204/lib/ 類似。
?
2. 添加 Shale 庫到 Web 應用程序中
下一步是將所有 Shale JAR 文件和庫添加到 Web 應用程序可以訪問和使用它們的位置。步驟如下:
1. 如果在 servlet 引擎中沒有包含 JSF,那么將 shale-framework-20060204/lib/jsf-ri/jsf-api.jar 和 shale-framework-20060204/lib/jsf-ri/jsf-impl.jar 復制到應用程序的 WEB-INF/lib 目錄中。
2. 將 shale-core.jar、shale-clay.jar、shale-tiles.jar 和 tiles-core.jar 從 shale-framework-20060204/dist/ 目錄復制到 Web 應用程序的 WEB-INF/lib 目錄。
3. 將以下 Shale 依賴項復制到 Web 應用程序的 WEB-INF/lib 目錄:
- o shale-framework-20060204/lib/commons-beanutils/commons-beanutils.jar
- o shale-framework-20060204/lib/commons-chain/commons-chain.jar
- o shale-framework-20060204/lib/commons-digester/commons-digester.jar
- o shale-framework-20060204/lib/commons-logging/commons-logging.jar
- o shale-framework-20060204/lib/commons-validator/commons-validator.jar
4. 如果要使用 Shale 的 Spring 集成特性,那么將 shale-spring.jar 從 shale-framework-20060204/dist/ 復制到 Web 應用程序的 WEB-INF/ 目錄。要完成這個步驟,還必須確保 Spring 的打包 JAR 文件也在 Web 應用程序的 WEB-INF/lib 目錄中。這個 JAR 文件名為 spring.jar,如果您還沒有這個文件的話,可以在 shale-framework-20060204/lib/shaleframework/ 目錄中找到它。
5. 如果正在使用 Java 5.0,那么將 shale-tiger.jar 從 shale-framework-20060204/dist/ 復制到 Web 應用程序 的 WEB-INF/lib 目錄中。只有在使用 Java 5.0 的時候才需要執行這一步;否則,servlet 引擎和使用 Shale 的 Web 應用程序就會出問題。
再往后走就開始復雜起來(是的,這些復制操作是較容易的一部分)。接下來的事情未必都要用最難的方式去做,至少我應該讓您有機會選擇 試試容易的方法。使 Shale 在系統上運行這個任務的確存在捷徑;您已經知道手動設置 Shale 的過程比較復雜,接下來有必要看看 “簡便” 方法。
更容易的方法
重新訪問 Shale 下載站點,并下載名稱類似于 shale-starter-20060204.zip 的 “starter” 應用程序。解壓這個歸檔文件,將得到一個名為 shale-starter/ 的目錄。這是一個基本上配置好的 Shale Web 應用程序,用于幫助避免前一節詳細介紹的復制和配置工作。首先要做的是將 shale-starter/ 目錄重新命名成應用程序以后要使用的名稱,例如可以將它命名為 first-shale/。進入 first-shale/ 目錄,在這里可以看到一些文件和子目錄。
在 first-shale/ 目錄中,創建一個名為 build.properties 的新文件。通過這個文件可以定制如何構建 Shale starter 應用程序,并確保該應用程序適合您的環境設置。清單 1 展示了一個基本的 build.properties 文件,可以根據自己的環境對其進行定制。
清單 1. Shale starter 應用程序的示例 build.properties
# Basic project information # Java package and context path for servlet engine # Directory for Shale distribution - change this for your system # Directory for all your libraries - change this for your system |
根據系統設置好這些屬性后,便可以運行 ant。Shale starter 應用程序開始構建 并(假設已經正確地設置了路徑)創建一個示例應用程序。如果有問題,則構建腳本輸出錯誤消息;這些錯誤消息都描述得很清楚,所以您應該可以更正任何錯誤。
構建過程的最后將生成一個名為 target/ 的新目錄。進入這個目錄,可以看到一個名為 first-app(即您在 build.properties 中為項目指定的名稱)的子目錄。大多數 servlet 引擎都允許將這個目錄整個地復制到 servlet 引擎的 webapps/ 目錄。例如,我使用的是 Tomcat,于是我將構建腳本創建的整個 first-shale 目錄復制到 /usr/local/java/tomcat/webapps。
?
構建 WAR 文件
如果使用的 servlet 引擎要求提供 WAR 文件,那么可以使用相同的 Shale starter 應用程序的構建文件,只需略微修改一下。由于還沒有為這個 Shale 應用程序編寫任何 Java 文件,當您請求一個 WAR 文件時,構建腳本將出現錯誤(在 build.xml 中有查找文件的 JavaScript 命令,但是沒有找到任何文件)。為了修復這個問題,打開 build.xml 文件,找到以 “javadoc” 開頭且如下所示的代碼:
<!-- ===================== Generate Documentation ======================== --> ??? <mkdir???????? dir="${build.docs.dir}"/> ??? <javadoc ??? <copy??????? todir="${build.docs.dir}"> ? </target> |
現在,注釋掉 javadoc 任務,如下所示:
? <!-- ===================== Generate Documentation ======================== --> ??? <mkdir???????? dir="${build.docs.dir}"/> ? </target> |
一旦開始為 Shale 應用程序開發 Java 代碼,便不必這樣做。不過對于現在,這樣做可以解決上述問題。保存修改后的 build.xml 并運行 ant dist。Ant 編譯和裝配 starter 應用程序,并在 dist/ 目錄中創建一個新的 WAR 文件。例如,我運行 ant dist 后得到一個 dist/first-shale-0.1.war 文件。現在可以將這個 WAR 文件復制到 servlet 引擎的 webapps/ 目錄。
測試安裝情況
如果完成了以上步驟,不管選擇的安裝路徑是什么,都應該可以啟動 servlet 引擎并通過地址 http://your.host.name/first-shale 訪問 Shale 應用程序。例如,如果在本地機器上運行 Tomcat,那么最終可以訪問的地址是 http://localhost:8080/first-shale。如果一切正常,那么應該可以看到如圖 2 所示的簡單頁面:
圖 2. Shale starter 應用程序證明一切沒問題
看起來似乎做了這么多工作卻所得甚少,但是要考慮到,通過打開并編輯一個簡單的 build.properties 文件,可以避免大量繁雜的復制和配置工作。您將發現,從空白的 Shale starter 應用程序開始總是開發新的 Shale 應用程序最容易的方式。實際上,當在下一篇文章中開始開發 Shale 應用程序的時候,將使用空白的 starter 應用程序作為開始的基礎。
Shale 用例
關于 Shale 的下載和安裝就介紹到這里,不過我們還是再花點兒時間從 Shale 主下載站點下載 Shale 的用例 WAR 應用程序。找到一個文件名形如 shale-usecases-20060204.war 的文件。下載該文件,并將它放入 servlet 引擎的 webapps/ 目錄,然后進入到這個 WAR。在我的系統上,訪問 http://localhost:8080/shale-usecases-20060204/ 并得到如圖 3 所示的屏幕:
圖 3. Shale 用例應用程序
您應該花些時間來看看這個用例應用程序。它有關于 Shale 中 Validator 和遠程報告等特性的很好的演示,并有一個簡單的 Ajax 應用程序。通過瀏覽這些用例,您可以了解到即使是簡單的 Shale 應用程序也可以做許多事情。
不過這里要提一個忠告:有些用例仍在開發中,取決于您何時下載每晚構建,可能發現有些用例不能正常工作。不過總是可以晚些時候再下載這些用例應用程序,看看有些問題是否已經被修復。雖然存在這些小問題,但是用例應用程序仍然是取得對 Shale 的基本印象的一種好途徑。
?????? 深入研究 Shale!
大多數 Web 開發人員向來只是使用已有的框架(例如 Shale、Struts 或 Spring)來開發他們的 Web 應用程序,而沒有做別的事情。當然這沒有什么錯,但是如果想理解一種框架以及它所涉及的技術,那么只能對框架本身做深入的研究。
對于 Shale(當然也包括 Struts),通過查看框架的內部,您可以學到大量關于 servlet 和 Web 開發的知識。如果想在自己的項目中使用一些 Shale 依賴項,這樣做還可以獲得難以置信的幫助。如果您對通過 Java 應用程序進行日志管理感興趣,那么通過 Shale 來熟悉 Apache Logging 項目比閱讀任何文章都要有效得多。對于 Jakarta Commons BeanUtils、Chain 或 Digester 項目也是一樣。這些都是很好的工具,對于開發人員很有用,所以花幾個星期或幾個月的時間探索一下 Shale 對于這些領域是一個很好的學習經歷。
由于本文是對 Shale 進行深入探討的系列中的第一期,因此如果我不對幾個對于 Shale 項目入門來說至關重要的方面進行討論的話,就是不負責任了。
親密接觸源代碼
不幸的是,關于 Shale 中涉及的開發過程的文檔并不多,所以如果您想直接使用 Shale 源代碼的話,需要用點兒技巧。一般來說,我這里給出的關于下載 Shale 并將它作為框架使用的說明也適用于下載 Shale 的源代碼。每晚構建包含 Shale 的所有源代碼,并且代碼的每個目錄中都有一個 build.xml 文件。
需要將下載的 Shale 的根目錄下的 build.properties.sample 文件復制到一個名為 build.properties 的文件中(去掉原始文件名尾部的 “.sample”)。清單 2 展示了這個文件的一個示例,為了簡潔起見,這里省略了其中一些注釋:
清單 2. 示例 Shale 構建文件
# This file contains example property settings that you would use to customize # Root directory into which you have unpacked the Shale Framework release. # Fully qualified pathname of the directory into which you have unpacked findbugs.outputFile=${root.dir}/find-bugs.html # The absolute or relative pathname of the Apache Struts spring.home=${lib.dir}/springframework |
為了與您的系統相匹配,需要更改這個構建文件中大部分的路徑。默認情況下,${basedir} 指向運行 Ant 時所在的目錄,因此如果是從下載的 Shale 的根目錄下運行 Ant,那么就剛好不用改路徑了。但是對于其他路徑,應該改為適當的與系統相匹配的路徑。例如,如果您的 JSF 參考實現在 c:/java/jsf-1_1_02 中,那么使用 jsfri.dir 目錄所在的路徑。大多數默認路徑都適合于使用 MyFaces(請參閱 “MyFaces 還是 JavaServer Faces”),但是當然也可以使用 Sun 的 JSF 實現,并對這些路徑作相應的更改。另外還需要設置 Struts、Spring(這是可選的,對于核心 Shale 框架來說不必要)和 FindBugs 項目的路徑。
Ant 登場
設置好這些文件的路徑后,就可以在 Shale 的根目錄中運行 Ant。但是,首先應該運行 ant download-dependencies。您當然也已經注意到,Shale 有很多 依賴項,而通過使用 Ant 自動下載這些依賴項可以為您節省很多時間,也令您輕松不少。Ant 腳本還負責設置路徑,以便使 Shale 與那些依賴項連接起來。還應該運行 ant copy-jsf-ri 來處理一些特定于 JSF 的任務(具體細節不必關心,因為 Ant 會為您打點一切)。
在構建主 Shale 發行版之前,應該運行 ant clean 刪除之前已有的構建后的代碼。雖然這意味著整個構建時間會更長,但是可以確保所有代碼將一致地構建。最后,運行 ant release,以便從頭開始構建 Shale。當這個 Ant 腳本運行完成后(這要花一點兒時間),就可以得到一個完整的、從源代碼構建的 Shale 發行版。
關于郵件列表的只言片語
開發源碼項目幾乎完全是通過電子郵件(再加上 Apache bug 跟蹤數據庫,在 參考資料 小節中有這方面的內容)來運作的。Shale 在這方面也是一樣的,不過它仍然使用 Struts 的郵件列表。如果在使用 Shale 時有什么疑問,可以發送電子郵件到 user@struts.apache.org。但是當您開始開發真正的 Shale 內部組件時,應該將電子郵件發送到 dev@struts.apache.org。不管將電子郵件發送到哪里,都應該以 “[shale]” 開頭,這樣別人一下子就明白您是要問關于 Shale 的問題,而不是關于 Struts 的問題。預期在幾個月后,當 Shale 開始成為獨立的項目時,它也會有它自己的郵件列表。
這里稍微提醒一下,尤其是在發送電子郵件到開發列表的時候:做好自己的工作,問題要有的放矢。那些飄忽不定、模棱兩可或缺乏思想的郵件很可能不會收到回復。如果您到處發送 “我想學習 Shale,請給我發送一些例子應用程序” 之類的郵件,甚至還可能得到粗魯的回答。雖然這種提醒看上去有些傻,但事實就是這樣。開發列表中總是充斥著這一類的問題,這些問題都是不受歡迎 的。通常,花點兒時間認真地斟酌您的問題,解釋一下您使用的平臺和軟件的版本,并說明您已經試過了一些常用的步驟。這樣一來,您的請求才會得到尊重并受到歡迎,也就更容易得到答案。開發人員的列表并不是令人生畏的,但最起碼這樣做顯得您尊重別人。
結束語
這個關于 Shale 的系列中的第一期文章說明,Shale 并不適合每一個人。Shale 沒有提供一個打包好的、有編制好的文檔并經過良好測試的產品,也沒有附帶自動安裝程序和優雅的管理界面,這些都是很多 Web 開發人員期待 Tapestry 時代能提供的東西。雖然在以后版本的框架中會體現這些東西(除了完全打包),但目前 Shale(從 2006 年初起)仍在開發過程中,并且 Shale 站點也基本上將它稱為處于 “alpha” 狀態的項目。Shale 中使用的很多組件是穩定和成熟的,但 Shale 本身仍然很年輕。如果您不能接受一些麻煩和困惑,那么可能會想過一年左右再開始使用它。
另一方面,如果您是一名對 Web 開發的前沿技術感興趣的 Java 開發人員,那么真應該看看 Shale 項目。雖然安裝 Shale 并使之工作要花費更多的精力,但是它完全有條件成為特別流行的 Web 開發框架。Shale 繼承了 Struts,同時也提供了一些全新的東西,這本身就值得作一番調查。對于有興趣成為開放源碼項目中的一員的開發人員,Shale 也是值得投入精力的一個項目。
歸于此類,因為shale與jsf有千絲萬縷的聯系