Struts的後代:Shale不是Struts

　　Shale 不是什麼?Shale 不是打包好的有編制好的文檔並經過嚴格測試的產品也沒有附帶自動安裝程序和優雅的管理界面那麼 Shale 到底是什麼呢?Brett McLaughlin 在本文中將揭開這個 Struts 後代的面紗在本文中Brett 解釋了 Shale 是什麼Shale 與 Struts 框架的不同之處以及如何在開發環境中安裝和設置它

 　　在過去 年間出現的所有 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 網站報道第一批代碼是在 年 月提交給 Struts CVS 存儲庫的而Struts 是在 年末才發布的當很多開發人員正在艱難地使用 JavaServer Pages(JSP)和不斷變化的 servlet 規范時Struts 提供了一種易於使用的 Model 方法來構建基於 servlet 和 JSP 的 Web 應用程序換句話說Struts 使 Web 開發人員可以開發健壯的 Web 應用程序而不必精於日志記錄分布式計算JDBCServletJSPJNDIRMI 和 大量其他的 API 和技術

　　接下來Struts 要做的事情就是保持它的強大性:從寫出第一批代碼開始Struts 連續 年一直是最流行的 Web 開發框架之一至今它仍然是人們口中的談資筆下的素材使用得不比任何競爭對手少由於 Struts 是如此流行如此長壽如今它已經有豐富的功能有良好的文檔被廣泛地支持並且易於使用在它上面進行開發和管理也很容易數千名開發人員對 Struts 郵件列表上的問題作出答復數萬名開發人員試用 Struts 並報告問題這使得這些問題很容易得到修復

　　最後Struts 是不斷發展的很多框架一開始比較強大然後就停滯不前(商業產品和開放源碼項目都存在這樣的現象)而 Struts 總是不斷提供新的特性當您下載 Struts 時核心發行版中還包含一個健壯的確認引擎(validation engine)並且 Struts 已經與 JavaServer Faces 集成擁有廣泛的標記庫和一個不斷發展的 Model 架構其中引入了在分布式 n層應用程序領域中最新的思想而且告訴您Struts 還緊跟程序設計中出現的新模式例如 IoC(Inversion of Control)Struts 與 WebWork 和 Spring 框架自然地集成後兩者都是具有最佳血統的為使用 Web 開發中的新方法提供入口的框架

　　簡而言之您很難發現在 Struts 中有做不成 或不支持的事所以顯然我們就要問為什麼 Shale 要另起爐灶呢?為什麼 Shale 沒有成為 Struts 的下一個版本呢?這有兩個主要原因:一個原因與鮮為人知的新軟件發行慣例有關另一個原因則與眾所周知的 Struts 根基中的弱點有關讓我們分別來考慮這兩個原因

　　發行版辨析

　　要理解 Shale 為什麼沒有成為 Struts 的一個新的發行版首先需要理解關於新軟件發行的一兩件事對於一個新的軟件發行版大多數用戶首先看的是一組新的特性版本升級的幅度越大用戶對新特性的期待就越大因此如果軟件版本從 升級到 就應該有一些新的特性但是如果從版本 升級到版本 那麼就應該有很多 新特性這就是為什麼當一些大型產品(例如 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 只是簡單地升級到 (或者 或 )並在不考慮向後兼容性的情況下實現 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) 或更高版本
　　Java Servlet API 或更高版本
　　JSP 或更高版本
　　JSF 或更高版本
　　JSP Standard Tag Library(JSTL) 或更高版本
　　Jakarta Commons BeanUtils 或更高版本
　　Jakarta Commons Chain 或更高版本
　　Jakarta Commons Digester 或更高版本
　　Apache Logging 或更高版本
　　Apache Ant 或更高版本

　　Apache Ant 只是在構建 Shale 時要用到但是無論如何如果您要進行較多的 Java 開發那麼系統上還是需要(很可能已經有了)一個版本的 Ant如果想跟蹤 Shale 中的 bug那麼需要 FindBugs 或更高版本和 JUnit 或更高版本由於在第 部分中我只是討論 Shale 的安裝和使用因此您還不必關心 FindBugs 或 JUnit除非您想早點兒裝上這兩個項目

　　附件和它們的依賴項

　　和 Struts 一樣Shale 還有一些附件(在 Shale 中常被稱作可選 Shale 組件)這些附件各自又有其依賴項:

　　Jakarta Commons Validator 或更高版本
　　Spring Framework 或更高版本
　　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 或更高版本 (servlet 引擎中可能已經附帶了)
　　JSTL 或更高版本 (servlet 引擎中可能已經附帶了)
　　Jakarta Commons BeanUtils 或更高版本
　　Jakarta Commons Chain 或更高版本
　　Jakarta Commons Digester 或更高版本
　　Apache Logging 或更高版本

　　考慮到 Tapestry 實際上提供了將它的所有依賴項附帶下載的選項因此 太多依賴項 的問題很快就不成為問題了

　　現在您已經知道了大概現在我們來看看下載安裝和配置 Shale 及其依賴項的步驟

　　 下載 Shale

　　要下載 Shale可訪問 Shale 項目主頁您可以看到一個 Shale Download 區域其中有 Shale 框架的每晚構建的鏈接單擊這個鏈接便可以進入如圖 所示的一個站點:

　　圖 來自 Shale CVS 存儲庫的每晚構建

　　為了使 Shale 運行需要下載 framework 文件和 dependencies 文件例如在撰寫本文時我下載了以下兩個文件:

　　shaleframeworkzip
　　shaledependencieszip

　　當然如果您需要或者更願意下載 targz 版本那麼可以不選擇 zip 版本而選擇 targz 版本由於 Shale 的開發還在進行中目前還沒有發行的構建因此您應該盡量下載最近的每晚構建(具有最近的日期)

　　下載完這兩個文件後首先解壓這兩個歸檔文件對於核心框架解壓後可以得到一個具有形如 shaleframework/ 的名稱的文件夾;對於 dependencies 歸檔文件解壓後可以得到一個名為 lib/ 的文件夾將核心框架目錄 shaleframework/ 轉移到您希望保存 Java 項目的地方例如在我的系統上我將 shaleframework/ 移動到 /usr/local/java 目錄中接下來將 lib/ 目錄移動到 Shale 目錄中所以最後的目錄結構與 shaleframework/lib/ 類似

　　 添加 Shale 庫到 Web 應用程序中

　　下一步是將所有 Shale JAR 文件和庫添加到 Web 應用程序可以訪問和使用它們的位置步驟如下:

　　 如果在 servlet 引擎中沒有包含 JSF那麼將 shaleframework/lib/jsfri/jsfapijar 和 shaleframework/lib/jsfri/jsfimpljar 復制到應用程序的 WEBINF/lib 目錄中

　　 將 shalecorejarshaleclayjarshaletilesjar 和 tilescorejar 從 shaleframework/dist/ 目錄復制到 Web 應用程序的 WEBINF/lib 目錄

　　 將以下 Shale 依賴項復制到 Web 應用程序的 WEBINF/lib 目錄:

　　o shaleframework/lib/commonsbeanutils/commonsbeanutilsjar
　　o shaleframework/lib/commonschain/commonschainjar
　　o shaleframework/lib/commonsdigester/commonsdigesterjar
　　o shaleframework/lib/commonslogging/commonsloggingjar
　　o shaleframework/lib/commonsvalidator/commonsvalidatorjar

　　 如果要使用 Shale 的 Spring 集成特性那麼將 shalespringjar 從 shaleframework/dist/ 復制到 Web 應用程序的 WEBINF/ 目錄要完成這個步驟還必須確保 Spring 的打包 JAR 文件也在 Web 應用程序的 WEBINF/lib 目錄中這個 JAR 文件名為 springjar如果您還沒有這個文件的話可以在 shaleframework/lib/shaleframework/ 目錄中找到它

　　 如果正在使用 Java 那麼將 shaletigerjar 從 shaleframework/dist/ 復制到 Web 應用程序 的 WEBINF/lib 目錄中只有在使用 Java 的時候才需要執行這一步;否則servlet 引擎和使用 Shale 的 Web 應用程序就會出問題

　　再往後走就開始復雜起來(是的這些復制操作是較容易的一部分)接下來的事情未必都要用最難的方式去做至少我應該讓您有機會選擇 試試容易的方法使 Shale 在系統上運行這個任務的確存在捷徑;您已經知道手動設置 Shale 的過程比較復雜接下來有必要看看 簡便 方法

　　更容易的方法

　　重新訪問 Shale 下載站點並下載名稱類似於 shalestarterzip 的 starter 應用程序解壓這個歸檔文件將得到一個名為 shalestarter/ 的目錄這是一個基本上配置好的 Shale Web 應用程序用於幫助避免前一節詳細介紹的復制和配置工作首先要做的是將 shalestarter/ 目錄重新命名成應用程序以後要使用的名稱例如可以將它命名為 firstshale/進入 firstshale/ 目錄在這裡可以看到一些文件和子目錄

　　在 firstshale/ 目錄中創建一個名為 buildproperties 的新文件通過這個文件可以定制如何構建 Shale starter 應用程序並確保該應用程序適合您的環境設置清單 展示了一個基本的 buildproperties 文件可以根據自己的環境對其進行定制

　　清單 Shale starter 應用程序的示例 buildproperties

　　

　　# Basic project information
pyright=My project Copyright ?
projectname=My First Shale Application
projectvendor=IBM DeveloperWorks
projectvendorid=comibmdw

　　# Java package and context path for servlet engine
projectpackage=comibmdwfirstShale
projectpath=firstshale

　　# Directory for Shale distribution change this for your system
shaledir=/usr/local/java/shaleframework

　　# Directory for all your libraries change this for your system
libdir=/usr/local/java/shaleframework/lib

　　根據系統設置好這些屬性後便可以運行 antShale starter 應用程序開始構建 並(假設已經正確地設置了路徑)創建一個示例應用程序如果有問題則構建腳本輸出錯誤消息;這些錯誤消息都描述得很清楚所以您應該可以更正任何錯誤

　　構建過程的最後將生成一個名為 target/ 的新目錄進入這個目錄可以看到一個名為 firstapp(即您在 buildproperties 中為項目指定的名稱)的子目錄大多數 servlet 引擎都允許將這個目錄整個地復制到 servlet 引擎的 webapps/ 目錄例如我使用的是 Tomcat於是我將構建腳本創建的整個 firstshale 目錄復制到 /usr/local/java/tomcat/webapps

　　構建 WAR 文件

　　如果使用的 servlet 引擎要求提供 WAR 文件那麼可以使用相同的 Shale starter 應用程序的構建文件只需略微修改一下由於還沒有為這個 Shale 應用程序編寫任何 Java 文件當您請求一個 WAR 文件時構建腳本將出現錯誤(在 buildxml 中有查找文件的 JavaScript 命令但是沒有找到任何文件)為了修復這個問題打開 buildxml 文件找到以 javadoc 開頭且如下所示的代碼:

　　

　　
             description="Create JavaDocs">

　　

　　            sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${pyright}">
     
   

　　
                    includes="**/*.gif"/>
   

　　

　　現在，注釋掉 javadoc 任務，如下所示:

　　

　　
             description="Create JavaDocs">

　　
<
                sourcepath="${src.java.dir}"
               destdir="${build.docs.dir}"
                author="false"
               private="true"
               version="true"
                source="${project.source}"
          packagenames="${project.package}.*"
           windowtitle="${project.name} (Version ${project.version})"
              doctitle="${project.name} (Version ${project.version})"
                bottom="${pyright}">
     
   
-->
   
                    includes="**/*.gif"/>
   

　　

　　一旦開始為 Shale 應用程序開發 Java 代碼，便不必這樣做。tw.wINGWIT.CoM不過對於現在，這樣做可以解決上述問題。保存修改後的 build.xml 並運行 ant dist。Ant 編譯和裝配 starter 應用程序，並在 dist/ 目錄中創建一個新的 WAR 文件。例如，我運行 ant dist 後得到一個 dist/first-shale-0.1.war 文件。現在可以將這個 WAR 文件復制到 servlet 引擎的 webapps/ 目錄。

　　測試安裝情況

　　如果完成了以上步驟，不管選擇的安裝路徑是什麼，都應該可以啟動 servlet 引擎並通過地址 -shale 訪問 Shale 應用程序。例如，如果在本地機器上運行 Tomcat，那麼最終可以訪問的地址是//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。在我的系統上，訪問//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
# your build environment to build the Struts Shale Library from
# source code.  To use this file, make a copy of it in "build.properties" and
# customize the values as required.

　　# Root directory into which you have unpacked the Shale Framework release.
root.dir=${basedir}

　　# Fully qualified pathname of the directory into which you have unpacked
# a binary distribution of the JavaServer Faces Reference Implementation
jsfri.dir=/usr/local/jsf-1_1_01

　　findbugs.outputFile=${root.dir}/l
lib.dir=${root.dir}/lib
jsf.home = ${lib.dir}/myfaces
jsf-api.jar = ${jsf.home}/myfaces-api.jar
jsf-impl.jar = ${jsf.home}/myfaces-impl.jar

　　# The absolute or relative pathname of the Apache Struts
# distribution
struts.home = /usr/local/jakarta-struts

　　spring.home=${lib.dir}/springframework
findbugs.home = /usr/local/findbugs-0.8.6

　　為了與您的系統相匹配，需要更改這個構建文件中大部分的路徑。默認情況下，${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 時有什麼疑問，可以發送電子郵件到 us。但是當您開始開發真正的 Shale 內部組件時，應該將電子郵件發送到 d。不管將電子郵件發送到哪裡，都應該以 “[shale]” 開頭，這樣別人一下子就明白您是要問關於 Shale 的問題，而不是關於 Struts 的問題。預期在幾個月後，當 Shale 開始成為獨立的項目時，它也會有它自己的郵件列表。

　　這裡稍微提醒一下，尤其是在發送電子郵件到開發列表的時候:做好自己的工作，問題要有的放矢。那些飄忽不定、模稜兩可或缺乏思想的郵件很可能不會收到回復。如果您到處發送 “我想學習 Shale，請給我發送一些例子應用程序” 之類的郵件，甚至還可能得到粗魯的回答。雖然這種提醒看上去有些傻，但事實就是這樣。開發列表中總是充斥著這一類的問題，這些問題都是不受歡迎 的。通常，花點兒時間認真地斟酌您的問題，解釋一下您使用的平台和軟件的版本，並說明您已經試過了一些常用的步驟。這樣一來，您的請求才會得到尊重並受到歡迎，也就更容易得到答案。開發人員的列表並不是令人生畏的，但最起碼這樣做顯得您尊重別人。

　　結束語

　　這個關於 Shale 的系列中的第一期文章說明，Shale 並不適合每一個人。Shale 沒有提供一個打包好的、有編制好的文檔並經過良好測試的產品，也沒有附帶自動安裝程序和優雅的管理界面，這些都是很多 Web 開發人員期待 Tapestry 時代能提供的東西。雖然在以後版本的框架中會體現這些東西(除了完全打包)，但目前 Shale(從 2006 年初起)仍在開發過程中，並且 Shale 站點也基本上將它稱為處於 “alpha” 狀態的項目。Shale 中使用的很多組件是穩定和成熟的，但 Shale 本身仍然很年輕。如果您不能接受一些麻煩和困惑，那麼可能會想過一年左右再開始使用它。

　　另一方面，如果您是一名對 Web 開發的前沿技術感興趣的 Java 開發人員，那麼真應該看看 Shale 項目。雖然安裝 Shale 並使之工作要花費更多的精力，但是它完全有條件成為特別流行的 Web 開發框架。Shale 繼承了 Struts，同時也提供了一些全新的東西，這本身就值得作一番調查。對於有興趣成為開放源碼項目中的一員的開發人員，Shale 也是值得投入精力的一個項目。

From:http://tw.wingwit.com/Article/program/Java/ky/201311/28480.html