mvn -e archetype:generate -B -DarchetypeGroupId=org.appfuse.archetypes -DarchetypeArtifactId=appfuse-basic-struts-archetype -DarchetypeVersion=3.5.0 -DgroupId=net.novogrodsky -DartifactId=myprojecthtml
http://www.ibm.com/developerworks/cn/java/j-appfuse/java
AppFuse 是一個開放源碼的項目和應用程序,它使用了在 Java 平臺上構建的開放源碼工具來幫助咱們快速而高效地開發 Web 應用程序。我最初開發它是爲了減小在爲客戶構建新 Web 應用程序時所花費的那些沒必要要的時間。從核心上來講,AppFuse 是一個項目骨架,相似於經過嚮導建立新 Web 項目時 IDE 所建立的東西。當咱們使用 AppFuse 建立一個項目時,它會提示咱們將使用開放源碼框架,而後才建立項目。它使用 Ant 來驅動測試、代碼生成、編譯和部署。它提供了目錄和包結構,以及開發基於 Java 語言的 Web 應用程序所須要的庫。程序員
與大部分 「new project」 嚮導不一樣,AppFuse 建立的項目從最開始就包含不少類和文件。這些文件用來實現特性,不過它們同時也會在您開發應用程序時被用做示例。經過使用 AppFuse 啓動新項目,咱們一般能夠減小一到兩週的開發時間。咱們不用擔憂如何將開放源碼框架配置在一塊兒,由於這都已經完成了。咱們的項目都已提早配置來與數據庫進 行交互,它會部署到應用服務器上,並對用戶進行認證。咱們沒必要實現安全特性,由於這都早已集成了。web
當我最初開發 AppFuse 時,它只支持 Struts 和 Hibernate。通過幾年的努力,我發現了比 Struts 更好的 Web 框架,所以我還添加了爲這些 Web 框架使用的選項。如今,AppFuse 能夠支持 Hibernate 或 iBATIS 做爲持久性框架。對於 Web 框架來講,咱們可使用 JavaServer Faces(JSF)、Spring MVC、Struts、Tapestry 或 WebWork。spring
AppFuse 提供了不少應用程序須要的一些特性,包括:數據庫
這種 「開箱即用」 的功能是 AppFuse 與其餘 CRUD 代 框架的區別之一(CRUD 取自建立、檢索、更新 和刪除 幾個操做的英文首字母),包括 Ruby on Rails、Trails 和 Grails。上面提到的這些框架,以及 AppFuse,都讓咱們能夠從數據庫表或現有的模型對象中生成主頁/細節頁。apache
圖 1 闡述了一個典型 AppFuse 應用程序的概念設計:安全
清單 1 給出了咱們在建立 devworks 項目時所使用的命令行交互操做,同時還給出了所生成的結果。這個項目使用了 WebWork 做爲本身的 Web 框架(請參考下面 參考資料 一節給出的連接)。服務器
alotta:~/dev/appfuse mraible$ ant new Buildfile: build.xml clean: [echo] Cleaning build and distribution directories init: new: [echo] [echo] +-------------------------------------------------------------+ [echo] | -- Welcome to the AppFuse New Application Wizard! -- | [echo] | | [echo] | To create a new application, please answer the following | [echo] | questions. | [echo] +-------------------------------------------------------------+ [input] What would you like to name your application [myapp]? devworks [input] What would you like to name your database [mydb]? devworks [input] What package name would you like to use [org.appfuse]? com.ibm [input] What web framework would you like to use [webwork,tapestry,spring,js f,struts]? webwork [echo] Creating new application named 'devworks'... [copy] Copying 359 files to /Users/mraible/Work/devworks [copy] Copying 181 files to /Users/mraible/Work/devworks/extras [copy] Copying 1 file to /Users/mraible/Work/devworks [copy] Copying 1 file to /Users/mraible/Work/devworks install: [echo] Copying WebWork JARs to ../../lib [copy] Copying 6 files to /Users/mraible/Work/devworks/lib [echo] Adding WebWork entries to ../../lib.properties [echo] Adding WebWork classpath entries [echo] Removing Struts-specific JARs [delete] Deleting directory /Users/mraible/Work/devworks/lib/struts-1.2.9 [delete] Deleting directory /Users/mraible/Work/devworks/lib/strutstest-2.1.3 [echo] Deleting struts_form.xdt for XDoclet [delete] Deleting directory /Users/mraible/Work/devworks/metadata/templates [echo] Deleting Struts merge-files in metadata/web [delete] Deleting 7 files from /Users/mraible/Work/devworks/metadata/web [echo] Deleting unused Tag Libraries and Utilities [delete] Deleting 2 files from /Users/mraible/Work/devworks/src/web/org/appfu se/webapp [echo] Modifying appgen for WebWork [copy] Copying 12 files to /Users/mraible/Work/devworks/extras/appgen [echo] Replacing source and test files [delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/ webapp/form [delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/ webapp/action [copy] Copying 13 files to /Users/mraible/Work/devworks/src [delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse /webapp/form [delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse /webapp/action [copy] Copying 5 files to /Users/mraible/Work/devworks/test [echo] Replacing web files (images, scripts, JSPs, etc.) [delete] Deleting 1 files from /Users/mraible/Work/devworks/web/scripts [copy] Copying 34 files to /Users/mraible/Work/devworks/web [delete] Deleting: /Users/mraible/Work/devworks/web/WEB-INF/validator-rules-c ustom.xml [echo] Modifying Eclipse .classpath file [echo] Refactoring build.xml [echo] ---------------------------------------------- [echo] NOTE: It's recommended you delete extras/webwork as you shouldn't ne ed it anymore. [echo] ---------------------------------------------- [echo] Repackaging info written to rename.log [echo] [echo] +-------------------------------------------------------------+ [echo] | -- Application created successfully! -- | [echo] | | [echo] | Now you should be able to cd to your application and run: | [echo] | > ant setup test-all | [echo] +-------------------------------------------------------------+ BUILD SUCCESSFUL Total time: 15 seconds
在建立一個新項目以後,咱們就獲得了一個相似於圖 2 所示的目錄結構。Eclipse 和 Intellij IDEA 項目文件都是做爲這個過程的一部分建立的。
這 個目錄結構與 Sun 爲 Java 2 Platform Enterprise Edition(J2EE)Web 應用程序推薦的目錄結構很是相似。在 2.0 版本的 AppFuse 中,這個結構會變化成適合 Apache Maven 項目的標準目錄結構(有關這兩個目錄介紹的內容,請參看 參考資料 中的連接)。AppFuse 還會從 Ant 遷移到 Maven 2 上,從而得到相關下載的能力和對生成 IDE 項目文件的支持。目前基於 Ant 的系統要求提交者維護項目文件,而 Maven 2 能夠經過簡單地使用項目的 pom.xml 文件生成 IDEA、Eclipse 和 NetBeans 項目文件。(這個文件位於您項目的根目錄中,是使用 Maven 構建應用程序所須要的主要組件)。它與利用 Ant 所使用的 build.xml 文件很是相似。)
如今咱們對 AppFuse 是什麼已經有一點概念了,在本文剩下的部分中,咱們將介紹使用 AppFuse 的 7 點理由。即便您選擇不使用 AppFuse 來開始本身的項目,也會看到 AppFuse 能夠爲您提供不少樣板代碼,這些代碼能夠在基於 Java 語言的 Web 應用程序中使用。因爲它是基於 Apache 許可證的,所以很是歡迎您在本身的應用程序中重用這些代碼。
測試是在軟件開發項目中不多被 給予足夠信任的一個環節。注意我並非說在軟件開發的一些刊物中沒有獲得足夠的信任!不少文章和案例研究都給出了測試優先的開發方式和足夠的測試覆蓋面以 提升軟件的質量。然而,測試一般都被看做是一件只會延長項目開發時間的事情。實際上,若是咱們使用測試優先的方法在編寫代碼以前就開始撰寫測試用例,我相 信咱們能夠發現這實際上會加速 開發速度。另外,測試優先也可使維護和重用更加 容易。若是咱們不編寫代碼來測試本身的代碼,那麼就須要手工對應用程序進行測試 —— 這一般效率都不高。自動化纔是關鍵。
當咱們首次開始使用 AppFuse 時,咱們可能須要閱讀這個項目 Web 站點上提供的快速入門指南和教程(請參看 參考資料 中的連接)。這些教程的編寫就是爲了您能夠首先編寫測試用例;它們直到編寫接口和/或實現以後才能編譯。若是您有些方面與我同樣,就會在開始編寫代碼以前 就已經編寫好測試用例了;這是真正能夠加速編寫代碼的唯一方式。若是您首先編寫了代碼的實現,經過某種方式驗證它能夠工做,那麼您可能會對本身說,「哦, 看起來不錯 —— 誰須要測試呢?我還有更多的代碼須要編寫!」這種狀況不幸的一面是您一般都會作一些事情 來測試本身的代碼;您簡單地跳過了能夠自動化進行測試的地方。
AppFuse 的文檔展現瞭如何測試應用程序的全部 層次。它從數據庫層開始入手,使用了 DbUnit(請參看 參考資料)在運行測試以前提早使用數據來填充本身的數據庫。在數據訪問(DAO)層,它使用了 Spring 的 AbstractTransactionalDataSourceSpringContextTests
類(是的,這的確是一個類的名字!)來容許簡單地加載 Spring 上下文文件。另外,這個類對每一個 testXXX()
方法封裝了一個事務,並當測試方法存在時進行回滾。這種特性使得測試 DAO 邏輯變得很是簡單,而且不會對數據庫中的數據形成影響。
在服務層,jMock (請參看 參考資料)用來編寫那些能夠消除 DAO 依賴的真正 單元測試。這容許進行驗證業務邏輯正確的快速測試;咱們不用擔憂底層的持久性邏輯。
在 Web 層,測試會驗證操做(Struts/WebWork)、控件(Spring MVC)、頁面(Tapestry)和管理 bean(JSF)如咱們所指望的同樣進行工做。Spring 的 spring-mock.jar 能夠很是有用地用來測試全部這些框架,由於它包含了一個 Servlet API 的仿真實現。若是沒有這個有用的庫,那麼測試 AppFuse 的 Web 框架就會變得很是困難。
UI 一般是開發 Web 應用程序過程當中最爲困難的一部分。它也是顧客最常常抱怨的地方 —— 這既是因爲它並非很是完美,也是因爲它的工做方式與咱們指望的並不同。另外,沒有什麼會比在客戶面前做演示的過程當中看到看到異常堆棧更糟糕的了!您的 應用程序可能會很是可怕,可是客戶可能會要求您作到十分完美。永遠不要讓這種事情發生。Canoo WebTest 能夠對 UI 進行測試。它使用了 HtmlUnit 來遍歷測試 UI,驗證全部的元素都存在,並能夠填充表單的域,甚至能夠驗證一個假想的啓用 Ajax 的 UI 與咱們預期的工做方式同樣。(有關 WebTest 和 HTMLUnit 的連接請參看 參考資料。)
爲了進一步簡化 Web 的測試,Cargo(請參看 參考資料)對 Tomcat 的啓動和中止(分別在運行 WebTest 測試以前和以後)進行了自動化。
正如我在本文簡介中提到的同樣,不少開放源碼庫都已經預先集成到 AppFuse 中了。它們能夠分爲如下幾類:
除 了這些庫以外,AppFuse 還使用 Log4j 來記錄日誌,使用 Velocity 來構建 e-mail 和菜單模板。Tomcat 能夠支持最新的開發,咱們可使用 1.4 或 5 版本的 Java 平臺來編譯或構建程序。咱們應該能夠將 AppFuse 部署到任何 J2EE 1.3 兼容的應用服務器上;這已經通過了測試,咱們知道它在全部主要版本的 J2EE 服務器和全部主要的 servlet 容器上均可以很好地工做。
圖 3 給出了上面建立的 devworks 項目的 lib 目錄。這個目錄中的 lib.properties 文件控制了每一個依賴性的版本號,這意味着咱們能夠簡單地經過把這些包的新版本放到這個目錄中並執行諸如 ant test-all -Dspring.version=2.0
之類的命令來測試這些包的新版本。
預先集成這些開放源碼庫能夠在項目之初極大地提升生產效率。儘管咱們能夠找到不少文檔介紹如何集成這些庫,可是定製工做示例並簡單地使用它來開發應用程序要更加簡單。
除了能夠簡化 Web 應用程序的開發以外,AppFuse 讓咱們還能夠將 Web 服務簡單地集成到本身的項目中。儘管 XFire 也在 AppFuse 下載中一塊兒提供了,不過若是咱們但願,也能夠本身集成 Apache Axis(請參看 參考資料 中有關 Axis 集成的教程)。另外,Spring 框架和 XFire 能夠一塊兒將服務層做爲 Web 服務很是簡單地呈現出來,這就爲咱們提供了開發面向服務架構的能力。
另 外,AppFuse 並不會將咱們限定到任何特定的 API 上。它只是簡單地對可用的最佳開放源碼解決方案從新進行打包和預先集成。AppFuse 中的代碼能夠處理這種集成,並實現了 AppFuse 的基本安全性和可用性特性。只要可能,就會減小代碼,以便向 AppFuse 的依賴框架添加一個特性。例如,AppFuse 自帶的 Remember Me 和 SSL 切換特性最近就由於相似的特性而從 Acegi Security 中刪除了。
Ant 使得簡化了從編譯到構建再到部署的自動化過程。Ant 是 AppFuse 中的一等公民,這主要是由於我發如今命令行中執行操做比從 IDE 中更加簡單。咱們可使用 Ant 實現編譯、測試、部署和執行任何代碼生成的任務。
盡 管這種能力對於有些人來講很是重要,可是它並不適用於全部的人。不少 AppFuse 用戶目前都使用 Eclipse 或 Intellij IDEA 來構建和測試本身的項目。在這些 IDE 中運行 Ant 的確能夠工做,可是這樣作的效率一般都不如使用 IDE 內置的 JUnit 支持來運行測試效率高。
幸運的是,AppFuse 支持在 IDE 中運行測試,不過管理這種特性對於 AppFuse 開發人員來講就變得很是困難了。最大的痛苦在於 XDoclet 用來生成 Hibernate 映射文件和 Web 框架所使用的一些工件(例如 ActionForms 和 Struts 使用的 struts-config.xml)。IDE 並不知道須要生成的代碼,除非咱們配置使用 Ant 來編譯它們,或者安裝了一些能夠認識 XDoclet 的插件。
這種對知識的缺少是 AppFuse 2.0 切換到 JDK 5 和 Maven 2 上的主要緣由。JDK 五、註釋和 Struts 2 將讓咱們能夠擺脫 XDoclet。Maven 2 將使用這些生成的文件和動態類路徑來生成 IDE 項目文件,這樣對項目的管理就能夠進行簡化。目前基於 Ant 的編譯系統已經爲不一樣的層次生成了一些工件(包括 dao.jar、service.jar 和 webapp.war),所以切換到 Maven 的模型上應該是一個很是天然的調整。
除了 Ant 以外(它對於編譯、測試、部署和報告具備豐富的支持),對於 CruiseControl 的支持也構建到了 AppFuse 中。CruiseControl 是一個 Continuous Integration 應用程序,讓咱們能夠在源代碼倉庫中代碼發生變化時自動運行全部的測試。extras/cruisecontrol 目錄包含了咱們爲基於 AppFuse 的項目快速、簡單地設置 Continuous Integration 時所須要的文件。
設置 Continuous Integration 是軟件開發週期中咱們首先要作的事情之一。它不但激發程序員去編寫測試用例,並且還經過 「You broke the build!」 遊戲促進了團隊之間的合做和融合。
AppFuse 最初是做爲我爲 Apress 編寫的書籍 Pro JSP 中示例應用程序的一部分開發的。這個示例應用程序展現了不少安全特性和用於簡化 Struts 開發的特性。這個應用程序中的不少安全特性在 J2EE 的安全框圖中都不存在。使用容器管理認證(CMA)的認證方法很是簡單,可是 Remember Me、密碼提示、SSL 切換、登記和用戶管理等功能卻都不存在。另外,基於角色的保護方法功能在非 EJB 環境中也是不可能的。
最初,AppFuse 使用本身的代碼和用於 CMA 的解決方案徹底實現了這些特性。我在 2004 年年初開始學習 Spring 時就據說過有關 Acegi Security 的知識。我對 Acegi 所須要的 XML 的行數(175)與 web.xml 中所須要的 CMA 的行數(20)進行了比較,很快就決定丟棄 Acegi 了,由於它太過複雜了。
一年半以後 —— 在爲另一本書 Spring Live 中編寫了一章有關使用 Acegi Security 的內容以後 —— 我就改變了本身的想法。Acegi 的確(目 前仍然)須要不少 XML,可是一旦咱們理解了這一點,它其實是至關簡單的。當咱們最終做出改變,使用 Acegi Security 的特性來所有取代 AppFuse 的特性以後,咱們最終刪除了大量的代碼。類之上的類都已經沒有了,「Acegi handles that now」 中消失的部分如今所有進入了 CVS 的 Attic 中了。
Acegi Security 是 J2EE 安全模型中曾經出現過的最好模型。它讓咱們能夠實現不少有用的特性,這些特性在 Servlet API 的安全模型中都不存在:認證、受權、角色保護方法、Remember Me、密碼加密、SSL 切換、用戶切換和註銷。它讓咱們還能夠將用戶證書存儲到 XML 文件、數據庫、LDAP 或單點登陸系統(例如 Yale 的 Central Authentication Service (CAS) 或者 SiteMinder)中。
AppFuse 對不少與安全性相關的特性的實現從一開始都是很是優秀的。如今 AppFuse 使用了 Acegi Security,這些特性 —— 以及更多特性 —— 都很是容易實現。Acegi 有不少地方均可以進行擴充:這是它使用巨大的 XML 配置文件的緣由。正如咱們已經經過去年的課程對 Acegi 進行集成同樣,咱們已經發現對不少 bean 的定義進行定製能夠更加緊密地與 AppFuse 創建聯繫。
Spring IoC 容器和 Acegi Security 所提供的簡單開發、容易測試的代碼和鬆耦合特性的組合是 AppFuse 是這麼好的一種開發平臺的主要緣由。這些框架都是不可插入的,容許生成乾淨的可測試代碼。AppFuse 集成了不少開放源碼項目,依賴注入容許對應用程序層進行簡單的集成。
有些人會將代碼生成稱爲代碼氣味的散播(code smell)。在他們的觀點中,若是咱們須要生成代碼,那麼極可能就會作一些錯事。我傾向於這種肯定本身代碼使用的模式和自動化生成代碼的能力應該稱爲代碼香味的瀰漫(code perfume)。若是咱們正在編寫相似的 DAO、管理器、操做或控件,而且不想爲它們生成代碼,那麼這就須要根據代碼的氣味來生成代碼。固然,當語言能夠爲咱們提供能夠簡化任務的特性時,一切都是那麼美好;不過代碼生成一般都是一個必需 —— 一般其生產率也很是高 —— 的任務。
AppFuse 中提供了一個基於 Ant 和 XDoclet 的代碼生成工具,名叫 AppGen。默認狀況下,常見的 DAO 和管理器均可以容許咱們對任何普通老式 Java 對象(POJO)進行 CRUD 操做,可是在 Web 層上這樣作有些困難。AppGen 有幾個特性能夠用來執行如下任務:
在運行 AppGen 時,您會看到提示說 AppGen 要從數據庫表或 POJO 中生成代碼。若是在命令行中執行 ant install-detailed
,AppGen 就會安裝 POJO 特定的 DAO、管理器以及它們的測試。運行 ant install
會致使 Web 層的類重用通用的 DAO 和默認存在的管理器。
爲了闡述 AppGen 是如何工做的,咱們在 devworks MySQL 數據庫中建立了如清單 2 所示的表:
create table cat ( cat_id int(8) auto_increment, color varchar(20) not null, name varchar(20) not null, created_date datetime not null, primary key (cat_id) ) type=InnoDB;
在 extras/appgen 目錄中,運行 ant install-detailed
。這個命令的輸出結果對於本文來講實在太長了,不過咱們在清單 3 中給出了第一部分的內容:
$ ant install-detailed Buildfile: build.xml init: [mkdir] Created dir: /Users/mraible/Work/devworks/extras/appgen/build [echo] [echo] +-------------------------------------------------------+ [echo] | -- Welcome to the AppGen! -- | [echo] | | [echo] | Use the "install" target to use the generic DAO and | [echo] | Manager, or use "install-detailed" to general a DAO | [echo] | and Manager specifically for your model object. | [echo] +-------------------------------------------------------+ [input] Would you like to generate code from a table or POJO? (table,pojo) table [input] What is the name of your table (i.e. person)? cat [input] What is the name, if any, of the module for your table (i.e. organization)? [echo] Running Middlegen to generate POJO...
要對 cat 表使用這個新生成的代碼,咱們須要修改 src/dao/com/ibm/dao/hibernate/applicationContext-hibernate.xml,來爲 Hibernate 添加 Cat.hbm.xml 映射文件。清單 3 給出了咱們修改後的 sessionFactory
bean 的樣子:
<bean id="sessionFactory" class="..."> <property name="dataSource" ref="dataSource"/> <property name="mappingResources"> <list> <value>com/ibm/model/Role.hbm.xml</value> <value>com/ibm/model/User.hbm.xml</value> <value>com/ibm/model/Cat.hbm.xml</value> </list> </property> ... </bean>
在運行 ant setup deploy
以後,咱們就應該能夠在部署的應用程序中對 cat 表執行 CRUD 操做了:
咱們在上面的屏幕快照中看到的記錄都是做爲代碼生成的一部分建立的,所以如今就有測試數據了。
咱們能夠找到 AppFuse 各個風味的教程,而且它們都以 6 種不一樣的語言給出了:中文、德語、英語、韓語、葡萄牙語和西班牙語。使用風味(flavor) 一詞,個人意思是不一樣框架的組合,例如 Spring MVC 加上 iBATIS、Spring MVC 加上 Hibernate 或 JSF 加上 Hibernate。使用這 5 種 Web 框架和兩種持久框架,能夠有好幾種組合。有關它們的翻譯,AppFuse 爲本身的默認特性提供了 8 種翻譯。可用語言包括中文、荷蘭語、德語、英語、法語、意大利語、葡萄牙語和西班牙語。
除了核心教程以外,還添加了不少教程(請參看 參考資料) 來介紹與各類數據庫、應用服務器和其餘開放源碼技術(包括 JasperReports、Lucene、Eclipse、Drools、Axis 和 DWR)的集成。
Apache 軟件基金會對於開放源碼有一個有趣的見解。它對圍繞開放源碼項目開發一個開放源碼社區最感興趣。它的成員相信若是社區很是強大,那麼產生高質量的代碼就是一個天然的過程。下面的內容引自 Apache 主頁:
「咱們認爲本身不只僅是一組共享服務器的項目,並且是一個開發人員和用戶的社區。」
AppFuse 社區從 2003 年做爲 SourceForge 上的一個項目(是 struts.sf.net 的一部分)啓動以來,已經得到了極大的增加。經過在 2004 年 3 月轉換到 java.net 上以後,它已經成爲這裏一個很是流行的項目,從 2005 年 1 月到 3 月成爲訪問量最多的一個項目。目前它仍然是一個很是流行的項目(有關 java.net 項目統計信息的連接,請參看 參考資料),不過在這個站點上它正在讓位於 Sun 贊助的不少項目。
在 2004 年年底,Nathan Anderson 成爲繼我以後第一個提交者。此後有不少人都加入了進來,包括 Ben Gill、David Carter、Mika G?ckel、Sanjiv Jivan 和 Thomas Gaudin。不少現有的提交者都已經經過各類方式做出了本身的貢獻,他們都幫助 AppFuse 社區成爲一個迅速變化而且很是有趣的地方。
郵 件列表很是友好,咱們試圖維護這樣一條承諾 「沒有問題是沒有人理會的問題」。咱們的郵件列表歸檔文件中唯一一條 「RTFM」 是從用戶那裏發出的,而不是從開發者那裏發出的。咱們絕對信奉 Apache 開放源碼社區的哲學。引用我最好的朋友 Bruce Snyder 的一句話,「咱們爲代碼而來,爲人們而留下」。目前,大部分開發者都是用戶,咱們一般都喜歡有一段美妙的時間。另外,大部分文檔都是由社區編寫的;所以, 這個社區的知識是很是淵博的。
咱們應該嘗試使用 AppFuse 進行開發,這是由於它容許咱們簡單地進行測試、集成、自動化,並能夠安全地生成 Web 應用程序。其文檔很是豐富,社區也很是友好。隨着其支撐框架愈來愈好,AppFuse 也將不斷改進。
從 AppFuse 2.0 開始,咱們計劃遷移到 JDK 5(仍然支持部署到 1.4)和 Maven 2 上去。這些工具能夠簡化使用 AppFuse 的開發、安裝和升級。咱們計劃充分利用 Maven 2 的功能來處理相關依賴性。咱們將碰到諸如 appfuse-hibernate-2.0.jar 和 appfuse-jsf-2.0.jar 之類的工件。這些工件均可以在 pom.xml 文件中進行引用,它們負責提取其餘相關依賴性。除了在本身的項目中使用 AppFuse 基類以外,咱們還能夠像普通的框架同樣在 JAR 中對這些類簡單地進行擴展,這應該會大大簡化它的升級過程,並鼓勵更多用戶將本身但願的改進提交到這個項目中。
若是沒有其餘問題,使用 AppFuse 可讓您始終處於 Java Web 開發的技術前沿上 —— 就像咱們同樣!