AppFuse 是一個開放源碼的項目和應用程序，它使用了在 Java 平台上構建的開放源碼工具來幫助我們快速而高效地開發 Web 應用程序。我最初開發它是為了減少在為客戶構建新 Web 應用程序時所花費的那些不必要的時間。從核心上來說，AppFuse 是一個項目骨架，類似於通過向導創建新 Web 項目時 IDE 所創建的東西。當我們使用 AppFuse 創建一個項目時，它會提示我們將使用開放源碼框架，然後才創建項目。它使用 Ant 來驅動測試、代碼生成、編譯和部署。它提供了目錄和包結構，以及開發基於 Java 語言的 Web 應用程序所需要的庫。
與大部分 “new project” 向導不同，AppFuse 創建的項目從最開始就包含很多類和文件。這些文件用來實現特性，不過它們同時也會在您開發應用程序時被用作示例。通過使用 AppFuse 啟動新項目，我們通常可以減少一到兩周的開發時間。我們不用擔心如何將開放源碼框架配置在一起，因為這都已經完成了。我們的項目都已提前配置來與數據庫進行交互，它會部署到應用服務器上，並對用戶進行認證。我們不必實現安全特性，因為這都早已集成了。
當我最初開發 AppFuse 時，它只支持 Struts 和 Hibernate。經過幾年的努力，我發現了比 Struts 更好的 Web 框架，因此我還添加了為這些 Web 框架使用的選項。現在，AppFuse 可以支持 Hibernate 或 iBATIS 作為持久性框架。對於 Web 框架來說，我們可以使用 JavaServer Faces（JSF）、Spring MVC、Struts、Tapestry 或 WebWork。
AppFuse 提供了很多應用程序需要的一些特性，包括：
認證和授權
用戶管理
Remember Me（這會保存您的登錄信息，這樣就不用每次都再進行登錄了）
密碼提醒
登記和注冊
SSL 轉換
URL 重寫
皮膚
頁面修飾
模板化布局
文件上載
這種 “開箱即用” 的功能是 AppFuse 與其他 CRUD 代 框架的區別之一（CRUD 取自創建、檢索、更新 和刪除 幾個操作的英文首字母），包括 Ruby on Rails、Trails 和 Grails。上面提到的這些框架，以及 AppFuse，都讓我們可以從數據庫表或現有的模型對象中生成主頁/細節頁。
圖 1 闡述了一個典型 AppFuse 應用程序的概念設計：
圖 1. 典型的 AppFuse 應用程序
清單 1 給出了我們在創建 devworks 項目時所使用的命令行交互操作，同時還給出了所生成的結果。這個項目使用了 WebWork 作為自己的 Web 框架。
清單 1. 使用 AppFuse 創建新項目
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
為什麼使用 WebWork？
Struts 社區最近在熱情地擁抱 WebWork，這種結合導致為 Java 平台提供了一個非常優秀的新 Web 框架：Struts 2。當然，Spring MVC 是一個非常優秀的基於請求的框架，但是它不能像 Struts 2 一樣支持 JSF。基於內容的框架（例如 JSF 和 Tapestry）也都很好，但是我發現 WebWork 更為直觀，更容易使用。
在創建一個新項目之後，我們就得到了一個類似於圖 2 所示的目錄結構。Eclipse 和 Intellij IDEA 項目文件都是作為這個過程的一部分創建的。
圖 2. 項目的目錄結構
這個目錄結構與 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 許可證的，因此非常歡迎您在自己的應用程序中重用這些代碼。
理由 1：測試
測試是在軟件開發項目中很少被給予足夠信任的一個環節。注意我並不是說在軟件開發的一些刊物中沒有得到足夠的信任！很多文章和案例研究都給出了測試優先的開發方式和足夠的測試覆蓋面以提高軟件的質量。然而，測試通常都被看作是一件只會延長項目開發時間的事情。實際上，如果我們使用測試優先的方法在編寫代碼之前就開始撰寫測試用例，我相信我們可以發現這實際上會加速 開發速度。另外，測試優先也可以使維護和重用更加 容易。如果我們不編寫代碼來測試自己的代碼，那麼就需要手工對應用程序進行測試 —— 這通常效率都不高。自動化才是關鍵。
當我們首次開始使用 AppFuse 時，我們可能需要閱讀這個項目 Web 站點上提供的快速入門指南和教程。這些教程的編寫就是為了您可以首先編寫測試用例；它們直到編寫接口和/或實現之後才能編譯。如果您有些方面與我一樣，就會在開始編寫代碼之前就已經編寫好測試用例了；這是真正可以加速編寫代碼的惟一方式。如果您首先編寫了代碼的實現，通過某種方式驗證它可以工作，那麼您可能會對自己說，“哦，看起來不錯 —— 誰需要測試呢？我還有更多的代碼需要編寫！”這種情況不幸的一面是您通常都會做一些事情 來測試自己的代碼；您簡單地跳過了可以自動化進行測試的地方。
AppFuse 的文檔展示了如何測試應用程序的所有 層次。它從數據庫層開始入手，使用了 DbUnit在運行測試之前提前使用數據來填充自己的數據庫。在數據訪問（DAO）層，它使用了 Spring 的 AbstractTransactionalDataSourceSpringContextTests 類（是的，這的確是一個類的名字！）來允許簡單地加載 Spring 上下文文件。另外，這個類對每個 testXXX() 方法封裝了一個事務，並當測試方法存在時進行回滾。這種特性使得測試 DAO 邏輯變得非常簡單，並且不會對數據庫中的數據造成影響。
在服務層，jMock用來編寫那些可以消除 DAO 依賴的真正 單元測試。這允許進行驗證業務邏輯正確的快速測試；我們不用擔心底層的持久性邏輯。
HtmlUnit 支持
HtmlUnit 團隊在 1.8 發行版中已經完成了相當多的工作來確保包可以與流行的 Ajax 框架（Prototype 和 Scriptaculous）很好地工作。
在 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 與我們預期的工作方式一樣。
為了進一步簡化 Web 的測試，Cargo對 Tomcat 的啟動和停止（分別在運行 WebTest 測試之前和之後）進行了自動化。
理由 2：集成
正如我在本文簡介中提到的一樣，很多開放源碼庫都已經預先集成到 AppFuse 中了。它們可以分為以下幾類：
編譯、報告和代碼生成：Ant、Ant Contrib Tasks、Checkstyle、EMMA、Java2Html、PMD 和 Rename Packages
測試框架：DbUnit、Dumbster、jMock、JUnit 和 Canoo WebTest
數據庫驅動程序：MySQL 和 PostgreSQL
持久性框架：Hibernate 和 iBATIS
IoC 框架：Spring
Web 框架：JSF、Spring MVC、Struts、Tapestry 和 WebWork
Web 服務：XFire
Web 工具：Clickstream、Display Tag、DWR、JSTL、SiteMesh、Struts Menu 和 URL Rewrite Filter
Security：Acegi Security
JavaScript 和 CSS：Scriptaculous、Prototype 和 Mike Stenhouse 的 CSS Framework
除了這些庫之外，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 之類的命令來測試這些包的新版本。
圖 3. 項目依賴性
預先集成這些開放源碼庫可以在項目之初極大地提高生產效率。盡管我們可以找到很多文檔介紹如何集成這些庫，但是定制工作示例並簡單地使用它來開發應用程序要更加簡單。
除了可以簡化 Web 應用程序的開發之外，AppFuse 讓我們還可以將 Web 服務簡單地集成到自己的項目中。盡管 XFire 也在 AppFuse 下載中一起提供了，不過如果我們希望，也可以自己集成 Apache Axis。另外，Spring 框架和 XFire 可以一起將服務層作為 Web 服務非常簡單地呈現出來，這就為我們提供了開發面向服務架構的能力。
另外，AppFuse 並不會將我們限定到任何特定的 API 上。它只是簡單地對可用的最佳開放源碼解決方案重新進行打包和預先集成。AppFuse 中的代碼可以處理這種集成，並實現了 AppFuse 的基本安全性和可用性特性。只要可能，就會減少代碼，以便向 AppFuse 的依賴框架添加一個特性。例如，AppFuse 自帶的 Remember Me 和 SSL 切換特性最近就因為類似的特性而從 Acegi Security 中刪除了。
理由 3：自動化
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 5、注釋和 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!” 游戲促進了團隊之間的合作和融合。
理由 4：安全特性和可擴展性
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 集成了很多開放源碼項目，依賴注入允許對應用程序層進行簡單的集成。
理由 5：使用 AppGen 生成代碼
有些人會將代碼生成稱為代碼氣味的散播（code smell）。在他們的觀點中，如果我們需要生成代碼，那麼很可能就會做一些錯事。我傾向於這種確定自己代碼使用的模式和自動化生成代碼的能力應該稱為代碼香味的彌漫（code perfume）。如果我們正在編寫類似的 DAO、管理器、操作或控件，並且不想為它們生成代碼，那麼這就需要根據代碼的氣味來生成代碼。當然，當語言可以為我們提供可以簡化任務的特性時，一切都是那麼美好；不過代碼生成通常都是一個必需 —— 通常其生產率也非常高 —— 的任務。
AppFuse 中提供了一個基於 Ant 和 XDoclet 的代碼生成工具，名叫 AppGen。默認情況下，常見的 DAO 和管理器都可以允許我們對任何普通老式 Java 對象（POJO）進行 CRUD 操作，但是在 Web 層上這樣做有些困難。AppGen 有幾個特性可以用來執行以下任務：
（使用 Middlegen 和 Hibernate 工具）從數據庫表中生成 POJO
從 POJO 生成 UI
為 DAO、管理器、操作/控制器和 UI 生成測試
在運行 AppGen 時，您會看到提示說 AppGen 要從數據庫表或 POJO 中生成代碼。如果在命令行中執行 ant install-detailed，AppGen 就會安裝 POJO 特定的 DAO、管理器以及它們的測試。運行 ant install 會導致 Web 層的類重用通用的 DAO 和默認存在的管理器。
為了闡述 AppGen 是如何工作的，我們在 devworks MySQL 數據庫中創建了如清單 2 所示的表：
清單 2. 創建一個名為 cat 的數據庫表
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 中給出了第一部分的內容：
清單 3. 運行 AppGen 的 install-detailed 目標
$ 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 的樣子：
清單 4. 將 Cat.hbm.xml 添加到 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 操作了：
圖 4. Cat 列表
圖 5. Cat 表單
我們在上面的屏幕快照中看到的記錄都是作為代碼生成的一部分創建的，因此現在就有測試數據了。
理由 6：文檔
我們可以找到 AppFuse 各個風味的教程，並且它們都以 6 種不同的語言給出了：中文、德語、英語、韓語、葡萄牙語和西班牙語。使用風味（flavor） 一詞，我的意思是不同框架的組合，例如 Spring MVC 加上 iBATIS、Spring MVC 加上 Hibernate 或 JSF 加上 Hibernate。使用這 5 種 Web 框架和兩種持久框架，可以有好幾種組合。有關它們的翻譯，AppFuse 為自己的默認特性提供了 8 種翻譯。可用語言包括中文、荷蘭語、德語、英語、法語、意大利語、葡萄牙語和西班牙語。
除了核心教程之外，還添加了很多教程 來介紹與各種數據庫、應用服務器和其他開放源碼技術（包括 JasperReports、Lucene、Eclipse、Drools、Axis 和 DWR）的集成。
理由 7：社區
Apache 軟件基金會對於開放源碼有一個有趣的看法。它對圍繞開放源碼項目開發一個開放源碼社區最感興趣。它的成員相信如果社區非常強大，那麼產生高質量的代碼就是一個自然的過程。下面的內容引自 Apache 主頁：
“我們認為自己不僅僅是一組共享服務器的項目，而且是一個開發人員和用戶的社區。”
AppFuse 社區從 2003 年作為 SourceForge 上的一個項目（是 struts.sf.net 的一部分）啟動以來，已經獲得了極大的增長。通過在 2004 年 3 月轉換到 java.net 上之後，它已經成為這裡一個非常流行的項目，從 2005 年 1 月到 3 月成為訪問量最多的一個項目。目前它仍然是一個非常流行的項目，不過在這個站點上它正在讓位於 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 開發的技術前沿上 —— 就像我們一樣！
