一、構建Ant環境 ①免安裝構建：如果你已經配置好Eclipse環境（3.0以上），那Ant環境就已經構建好了； ②從零開始手工配置： A：配置好Java環境； 安裝JDK，然后設置好環境變量，如：
B、下載Ant包： 地址：http://ant.apache.org/bindownload.cgi 配置Ant環境變量：
測試：run-》cmd，輸入ant，如果出現下面的畫面，測表明Ant環境已經配置好了。 二、簡單上手： build.xml
HelloAnt.java
三、Ant提高
改進build.xml，讓它做更多的事情： 定義全局變量 初始化，主要是建立目錄 編譯（已有） 打包為jar 建立API documentation 生成 發布（distribution） 產品
1944年冬，盟軍完成了對德國的鐵壁合圍，法西斯第三帝國覆亡在即。整個德國籠罩在一片末日的氣氛里，經濟崩潰，物資奇缺，老百姓的生活陷入嚴重困境。
對普通平民來說，食品短缺就已經是人命關天的事，更糟糕的是，由于德國地處歐洲中部，冬季非常寒冷，家里如果沒有足夠的燃料的話，根本無法捱過漫長的冬天。在這種情況下，各地政府只得允許讓老百姓上山砍樹。 你能想像帝國崩潰前夕的德國人是如何砍樹的嗎？在生命受到威脅時，人們非但沒有去哄搶，而是先由政府部門的林業人員在林海雪原里拉網式地搜索，找到老弱病殘的劣質樹木，做上記號，再告誡民眾：如果砍伐沒有做記號的樹，將要受到處罰。在有些人看來，這樣的規定簡直就是個笑話：國家都快要滅亡了，誰來執行處罰？ 當時的德國，由于希特勒做垂死掙扎，幾乎將所有的政府公務人員都抽調到前線去了，看不到警察，更見不到法官，整個國家簡直就是處于無政府狀態。但令人不可思議的是，直到第二次世界大戰徹底結束，全德國竟然沒有發生過一起居民違章砍伐無記號樹木的事，每一個德國人都忠實地執行了這個沒有任何強制約束力的規定。 這是著名學者季羨林先生在回憶錄《留德十年》里講的一個故事。當時他在德國留學，親眼目睹了這一幕，所以事隔五十多年，他仍對此事感嘆不已，說，德國人"具備了無政府的條件卻沒有無政府的現象"。 是一種什么樣的力量使得德國人在如此極端糟糕的情況下，仍能表現出超出一般人想像的自律？答案只有兩個字：認真。因為認真是一種習慣，它深入到一個人的骨髓中，融化到一個人的血液里。因了這兩個字，德意志民族在經歷了上個世紀初中葉兩次毀滅性的世界大戰之后，又奇跡般地迅速崛起。 再講一個關于德國人認真的小故事。 熟悉柴油機制造業的人都知道有這樣一個說法：中國制造的柴油機，噪音在數公里外都聽得見，柴油機周圍數十平方米都是油跡；而德國人生產的柴油機則可以放在辦公室的地毯上工作，根本不會影響隔壁房間的人辦公。 于是，1984年，武漢柴油機廠聘請德國退休企業家格里希任廠長。 格里希上任后開的第一個會議，市有關部門領導也列席參加了。沒有任何客套，格里希便單刀直入，直奔主題："如果說質量是產品的生命，那么，清潔度就是氣缸的質量及壽命的關鍵。"說著，他當著有關方面領導的面，在擺放在會議桌上的氣缸里抓出一大把鐵砂，臉色鐵青地說："這個氣缸是我在開會前到生產車間隨機抽檢的樣品。請大家看看，我都從它里面抓出來了些什么？在我們德國，氣缸雜質不能高于50毫克，而我所了解的數據是，貴廠生產的氣缸平均雜質竟然在五千毫克左右。試想，能夠隨手抓得出一把鐵砂的氣缸，怎么可能雜質不超標？我認為這決不是工藝技術方面的問題，而是生產者和管理者的責任心問題，是工作極不認真的結果。"一番話，把坐在會議室里的有關管理人員說得坐立不安，尷尬之極。 兩年后，格里希因種種原因卸職時，武漢柴油機廠生產的氣缸雜質已經下降到平均一百毫克左右?；貒?，格里希有幾次來中國，每次都要到武漢柴油機廠探望。在廠里，他有時拿著磁頭檢查捧發現氣缸有未清除干凈的鐵粉時，忘了自己已經不是廠長，仍然生氣地向周圍陪同的人大聲咆哮："你們怎么能這么不認真！" 如果說強大的德意志是一個可怕的民族，那么，認真也是一種可怕的力量，它大能使一個國家強盛，小能使一個人無往而不利。我們實在該好好學習德國人認真得近乎刻板的精神，將認真貫徹到自己點點滴滴的行為中。一旦認真二字也深入到自己的骨髓，融化進自己的血液，你也會煥發出一種令所有的人，包括自己，都感到害怕的力量。 作者簡介：湘籍。1991年畢業于武漢大學中文系。曾在《獨生子女》、《良友》雜志供職?，F為自由撰稿人。
一個軟件項目從開始到結束，由于資源、人員、管理、方法學等等各方面的因素，往往不可避免的會存在一些問題，如需求不明確、項目管理失敗、溝通問題等等，今天無意中看到老外寫的關于這方面的一篇文章，總結的比較全面，翻譯過來結合自己的一些經驗做了點補充和修改，存檔以備時?？梢愿嬲]一下自己。
1、不能很好的理解用戶的需求，缺少與用戶之間的溝通。2、錯誤的預估項目的大小和難易度。3、沒有計劃就匆匆開始編碼。4、沒有在項目初期就開始做測試，一直拖到項目后期才做，或者根本不做什么測試。5、選擇時下最cool的技術還是已經被團隊使用比較成熟的技術，往往不能做出很正確的選擇。6、不采用任何軟件過程或者方法學。7、沒有一個真正的項目經理，讓開發人員無計劃的主導項目。8、拖延計劃，把進度壓力留在后期。9、不做版本控制，混亂的代碼庫和開發環境。10、在項目過程中隨意的更換開發工具和環境。11、客戶的任何需求都答應下來，需求會永無止境，記得學會說“不”。12、只有一個大的計劃，沒有把計劃分割成一個個更小的任務，要知道，大的計劃如果不分割成任務很難落實和具體實施。13、對開發團隊的管理不足。14、在項目后期增加人員來加快開發速度，很多時候往往適得其反。15、開發人員不做單元測試。16、一旦項目中遇到問題，就把壓力拋給開發人員。17、不關注軟件實際的運營環境和硬件條件。18、沒有命名規范和代碼規范。19、到處都用全局變量。20、遇到問題的時候往往不請教別人，而是一個人悶頭搞，到最后還是不得以還是通過別人來解決。21、沒有寫代碼注釋的習慣。22、對輸入輸出的數據不做驗證。23、不做壓力測試，到實際環境中往往就會出現更多的跟環境和性能相關的問題。24、項目內部溝通不暢，每個成員只是埋頭做自己的事情。25、沒有很好的bug管理規范和系統，往往用word、email、excel等文本方式來跟蹤bug，將會導致整個項目的bug管理陷入混沌。
其次，在值變函數中添加：FacesContext context = FacesContext.getCurrentInstance();...context.renderResponse();就可以了。