Jazz隨筆

非技術性文章請移駕至…

2007-08-26T12:23:00.001+08:00

http://jacklu0827.blogspot.com/

Maven2 Report使用cobertura-maven-plugin

2007-08-07T14:39:00.000+08:00

簡介一下Maven2中cobertura-maven-plugin進行Cobertura Report的使用。

更詳細的用法請參考：http://mojo.codehaus.org/cobertura-maven-plugin/

簡易使用法：

基本上只要在reporting標籤中使用進行plugin的設定即可。之後在執行maven site時就會產生測試覆蓋率的報表資料。

</plugins>

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.0</version>
</plugin>

</plugins>

</reporting>

為何我在這裏特別指定了Plugin的版本。
因為截至目前為止cobertura這個Plugin版本最新為2.1。
但釋出的2.1版中對於產生的報表結果有些問題。
基本上應該經過Maven2中的對Plugin的參數設定才能產生出想要的結果。

但一般使用上並不需要那麼繁覆，而2.0版本只要單純設好Plugin即可產出想要的測試覆蓋率結果。

莫非定律

2007-08-06T16:47:00.000+08:00

最近我偶爾會跟朋友們或講課時提到「莫非定律」。
在網路上看到幾篇的描述還滿生動的，整理如下：

參考網址：
莫非定律
莫非定律前十名

莫非定律是關於事情如何出錯的幽默規則，簡練地揭露了「人生總難事事順遂」這條顛撲不破的真理。
一切從莫非原始定律發展出來：會出錯的事，一定出錯。（If something can go wrong, it will.）

莫非定律誕生於1949年，以Edward A. Murphy（生於1917年）命名，他是愛德華空軍基地的工程師，專門研究人類對加速度承受的能力。
他發現同仁總會把加速計的固定器裝反，因而脫口而出他的觀察。有受試者在記者會上引述這句名言，於是很快在航太工程研究者之間散播開來，並陸續有人加上新的法則。

1958年，「莫非定律」正式被列入韋氏字典（Webster’s Dictionary）。
但是莫非本人從未發表過莫非定律，這點倒是蠻符合莫非定律的。
莫非定律至今已經發展出各種類別，從莫非通則到電腦、家庭、工作、政府等等，各種領域都有人找出屬於他們自己的莫非定律。

你可曾有過這樣的經驗？不帶傘時，偏偏下雨；帶了傘時，偏不下雨！
在門外，電話鈴猛響；進了門，就不響了！
這樣的事兒總是無可奈何，但在我們日常生活中卻是常有！

「莫非定律」講的正是你我的尷尬，點的正是你我共同的弱點，騷的
正是你我共同的癢處！自從我無意間在光華商場翻到它：「莫非定律
」，那一刻起，它便成了我的聖經！我相信讀過它，它也會成為你的！

莫非者，查無其人，是個虛構人物：一九五○年代美國海軍的教育宣
導卡通裡面，有個笨手笨腳的機械士叫做莫非。所謂莫非定律，最
早就是出自這部卡通。後來又衍生出各式各樣的莫非定律，原來的
那一則因而又被稱為莫非第一定律 (Murphy's First Law)。

莫非定律風行一時，世界各地的人都能琅琅上口。不少好事者也動
腦筋想出各式各樣的定律原理，其中不乏許多有趣的想法。

★莫非定律

一、別試圖教豬唱歌，這樣不但不會有結果，還會惹豬不高興!
二、別跟傻瓜吵架，不然旁人會搞不清楚，到底誰是傻瓜!
三、不要以為自已很重要，因為沒有你，太陽明天還是一樣從東方升上來!

●開宗明義
莫非定律；凡事只要有可能出錯，那就一定會出錯。
莫非哲學；笑一笑，明天未必比今天好。
莫非準則；東西越好，越不中用。

●開始
好的開始，未必就有好結果。
壞的開始，結果往往會更糟。

●人
你若幫助了一個急需用錢的朋友，他一定會記得你─( 在他下次急需用錢的時候。)

●領導人
愚人居高位，正如一個人置身山頂，他會小看每個人。
每個人也會小看他。

●智愚之間
有能力的──讓他做。
沒能力的──教他做。
做不來的──管理他。

●愛情
你愛上的人，總以為你愛上他是因為；他使你想起你的老情人。
你最後硬著頭皮寄出的情書；寄達對方的時間有多長，你反悔的時間就有多長。

●早到與晚到
你早到了，會議卻取消。
你準時到，卻還要等。
遲到，就是遲了。

●品質保證
一種產品保證60天不會故障，等於保證第61天一定就會壞掉

●東西
東西久久都派不上用場，就可以丟掉。
東西一丟掉，往往就必須要用它。

●尋找失物
你丟掉東西時，最先去找的地方，往往也是可能找到的最後一個地方。
你往往會找到不是你正想找的東西。

●精彩
你出去買爆米花的時候，銀幕上偏偏就出現了精彩鏡頭。

●排隊
另一排總是動的比較快。
你換到另一排，你原來站的那一排，就開始動的比較快了。
你站的越久，越有可能是站錯了排。

●失事報導
失事的地點越遠，傷亡的人數就得越多，否則寫不成一則故事。

●攜伴出遊
你攜伴出遊，越不想讓人看見，越會遇見熟人。

●相對論
一分鐘有多長？
這要看你是蹲在廁所裡面，還是等在廁所外面。

●撥錯電話號碼
撥錯電話號碼時，總不會打不通。

●結局
有個恐怖的結局，總好過恐怖綿綿無絕期。

莫非定律前十名
Top Ten Murphy's Laws

1.Notheing is as easy as it looks.
萬物皆比表象難

2.Everything takes longer than you think.
凡事耗費的時間都比原先料想的長。

3.Anything that can go wrong will go wrong.
可能會出錯的地方定會出錯。

4.If there is a possibility of several things going wrong,
the one that will cause the most damage will be the one to go wrong.
如果有好幾件事都有出錯的可能，定會出錯者就會是可能造成最嚴重損失的那一個。

5.If any things simply cannot go wrong, it will anyway.
鐵定不會出錯的的是一定會砸鍋。

6.If everything seems to be go wrong, you have obviously overlooked something.
如果事事乍看順利，那顯然是由某個地方沒有注意到。

7.Nature always sides with the hidden flaw.
所有的隱藏缺陷都會因為各種自然因素而被暴露出來。

8.It's impossible to make anything foolproof because fools are so ingenious.
要把所有東西都弄得萬無一失是不可能的，因為蠢蛋都太天才了，肯定會搞砸。

9.Where you set out to do something, something else must be done first.
每當你準備要做某件事時，就會有另一件得先處理的事情冒出來。

10.Every solution breeds new problems.
每一個問題的解決都會引發新的問題。

(2006.08月號--151期) 如何以Maven協助Hibernate開發

2007-08-05T19:03:00.000+08:00

在今日的企業級應用開發環境中，物件導向開發方式已成為主流，但在實際的應用中，物件只存在於程式與記憶體之中，並不能直接進行儲存。如果想要永久保存物件狀態，則必須要進行物件的持久化，也就是把物件狀態儲存進專門的資料庫系統中，而目前最廣泛使用的關聯式資料庫(RDBMS)，並不支援儲存物件導向數據資料。

因此傳統的關聯式資料庫程式設計，必須直接在程式中以Hard code的方式撰寫SQL語法進行開發，而以Hard code撰寫SQL語法的方式，相對的也代表了開發的應用程式無法跨資料庫平台。雖然JDBC統一了Java程式與資料庫之間的操作介面，讓開發人員可以不用了解與資料庫相關特定的API操作，然而自行撰寫SQL語法或再次將SQL語法進行封裝仍是不可避免的事，而在物件導向程式設計之中，物件與關聯式資料並無法以簡單的方式進行轉換，導致了資料永續性的開發上受到了先天的限制。

ORM(Object/Relational Mapping)物件-關聯映射技術，在該問題的處理上已經有完善的解決方案，而目前在開放原始碼的技術中，最受人矚目的ORM實作，應該就是Hibernate了。在本期中筆者將介紹如何使用Maven協助Hibernate進行快速開發，而對於Hibernate的基本觀念，筆者在此並不詳述，請參考之前刊載於RunPC中的相關文章。

註：關於Hibernate文章，請參考RunPC於128、129、130、132期，資料永續層解決方案Hibernate的相關介紹，作者為Mark Ho。

設定hibernatedoclet環境

在開發過程中Hibernate進行物件與關聯式資料的處理過程中，需要有一份映射文件，用以描述物件與關聯式資料的轉換關係，例如：資料型態的對應、資料欄位長度的限制、單向關聯、雙向關聯、一對多、一對一與多對多關聯等等的設定。一般而言映射文件命名通常為*.hbm.xml。

然而在實際開發上當物件作了修改或重構後，必須對映射文件進行維護。如此的開發方式相當的不直覺與不方便。並且學習映射文件的撰寫不是一件簡單的事。

因此我們換一個角度思考，如果在物件的設計中，順手將這些轉換關係的資訊寫在物件中，由物件編譯過程中直接幫我們產生相關的映射文件，則我們只要維護一份原始碼即可，當進行修改與重構的過程中，映射檔案的變更也將立即的反應出來。在此我們將使用XDoclet進行Code generate來達到這個目的。

註：有關於XDoclet相關觀念的文章，請參考RunPC於130、131期，XDoclet入門篇與進階篇，作者為歐宣修。

首先請參考筆者於148期中的Maven文章，使用Maven Genapp Plugin產生專案，並且參考設定 1將project.xml進行修改，在該檔中可以看到我們在Maven相依的plugin套件中加入了maven-xdoclet-plugin。接著參考設定 2對 project.properties加入設定參數。說明請參考表 1中關於hibernatedoclet的參數設定。最後再對maven.xml進行設定，參考設定 3中可知當我們執行java:compile這個goal前會先行運作xdoclet:hibernatedoclet協助我們產生Mapping file。

設定 1 project.xml

<?xml version="1.0" encoding="UTF-8"?>

<artifactId>hibernate-example</artifactId>

<groupId>hibernate-example</groupId>

<name>Example Hibernate Application</name>

<groupId>xdoclet</groupId>

<artifactId>maven-xdoclet-plugin</artifactId>

<type>plugin</type>

</dependency>

…中間省略…

</dependencies>

…中間省略…

</project>

設定 2 project.properties

#####################################

# hibernatedoclet properties

#####################################

maven.xdoclet.hibernatedoclet.fileset.0=true

maven.xdoclet.hibernatedoclet.fileset.0.sourcedir=${maven.src.dir}/java

maven.xdoclet.hibernatedoclet.fileset.0.include=**/*.java

maven.xdoclet.hibernatedoclet.fileset.0.exclude=

maven.xdoclet.hibernatedoclet.hibernate.0=true

maven.xdoclet.hibernatedoclet.hibernate.0.Version=3.0

maven.xdoclet.hibernatedoclet.destDir=${maven.build.dest}

設定 3 maven.xml

<?xml version="1.0" encoding="UTF-8"?>

<project

xmlns:j="jelly:core"

xmlns:ant="jelly:ant">

</preGoal>

</project>

表 1 maven-xdoclet-plugin設定

參數	說明
maven.xdoclet.hibernatedoclet.fileset.[index]	設定hibernatedoclet引用的檔案集設定，index值為0~9共10組設定，也就是說最多可以針對10組路徑下的原始檔進行hibernatedoclet的Code generate，預設index=0為啟用。若指定的maven.xdoclet.hibernatedoclet.fileset.[index]未設定，則以下相對應的檔案集設定即無效。
maven.xdoclet.hibernatedoclet.fileset.[index].sourcedir	指定檔案集原始碼放置路徑，預設為${maven.src.dir}/java
maven.xdoclet.hibernatedoclet.fileset.[index].include	指定檔案集引入檔案規則，預設為*/.java
maven.xdoclet.hibernatedoclet.fileset.[index].exclude	指定檔案集排除檔案規則，預設不排除任何檔。
maven.xdoclet.hibernatedoclet.hibernate.[index]	設定對maven.xdoclet.hibernatedoclet.fileset.[index]進行hibernatedoclet是否生效，預設為true，若為false則對指定的檔案集不執行hibernatedoclet。
maven.xdoclet.hibernatedoclet.hibernate.[index].Version	設定對maven.xdoclet.hibernatedoclet.fileset.[index]進行hibernatedoclet所產生的*.hbm.xml檔案可使用於hibernate那個版本，預設為1.1版，目前可設定的值為目前有1.1、 2.0、2.1、3.0。
maven.xdoclet.hibernatedoclet.destDir	所有檔案集產生出的*.hbm.xml放置的目的路徑。

建立Domain Object並產生Mapping File

當上一節的設定完成後，我們正式建立Domain Object，並試圖產生Hibernate所需要的Mapping file。這裏我們

是以POJO定義Domain Object，而POJO就是所謂的Plain Ordinary Java Object，字面上來講就是無格式普通Java 物件，簡單的可以理解爲一個不包含邏輯程式碼的值物件。

我們在此建立二個POJO，分別是User(使用者)與Role(所屬角色)作為開始。這時Maven專案架構應該如資料結構 1所示，圖 1展示了類別屬性與其set、get相關method。接著參考程式 1、程式 2分別在類別中加入<hibernatedoclet>Tag設定，在此我們簡單的了解一下相關屬性用途，若讀者希望了解更詳細的屬性設定，可參考XDoclet官方網站http://xdoclet.sourceforge.net/xdoclet/tags/hibernate-tags.html。

@hibernate.class：該Tag用於宣告定義持久化類別，需放置於Class宣告的上方。
1. table：指定持久化類別對應資料庫Table名稱。
@hibernate.id：定義主鍵欄位相關屬性。
1. column：指定欄位對應資料庫欄位名稱，若未指定則使用相對應的property名稱。
2. generator-class：主鍵產生器屬性，目前有uuid.hex、uuid.string、increment、assigned、native、identity、sequence、hilo、seqhilo、foreign可供設定。
@hibernate.property：定義持久化類別對應資料庫欄位相關屬性。
1. column：指定欄位對應資料庫欄位名稱，若未指定則使用相對應的property名稱。
2. length：指定對應資料庫欄位長度。
3. not-null：是否允許欄位存放null值。
4. unique：是否允許資料庫欄位值重覆
5. type：對應資料庫欄位型態

另外，讀者可能發現，在範例中的二個POJO都實現了java.io.Serializable介面，這是Hibernate規範中所提到的，但目前大多數資料並未說明為何必須實現Serializable。事實上Hibernate並不要求持久化類必須實現Serializable介面，但是對於採用分散式架構的Java應用，當Java物件在不同的分散節點之間傳輸時(例如：RMI)，這個物件所屬的類別必須實現Serializable介面，此外，在Java Web應用中，如果希望對HttpSession中存放的Java物件進行持久化，那麼這個Java物件所屬的類也必須實現Serializable介面，因此若只拿Hibernate作單純資料庫應用可不遵守該規定外，Hibernate在J2EE的應用上都是必須實現Serializable的。

經過maven的設定與撰寫完POJO後，在Console下執行maven java:compile，當指令運作結束後，在[hibernate_example/target/classes/demo/model]路徑下將會出現User.hbm.xml與Role.hbm.xml的Hibernate Mapping file。

資料結構 1

hibernate-example

|--src

| --main

| --java

| --demo

| --model

| |--Role.java

| --User.java

|--maven.xml

|--project.properties

--project.xml

圖 1 Domain Object類別圖

程式 1 User.java

package demo.model;

import java.io.Serializable;

/**

* @hibernate.class table="app_user"

public class User implements Serializable {

private Long id;

private String username;

private String password;

/**

* @hibernate.id column="id" generator-class="native"

public Long getId() {

return id;

}

/**

* @hibernate.property length="50" not-null="true" unique="true"

public String getUsername() {

return username;

}

/**

* @hibernate.property column="password" not-null="true"

public String getPassword() {

return password;

}

…set method 省略…

}

程式 2 Role.java

package demo.model;

import java.io.Serializable;

/**

* @hibernate.class table="role"

public class Role implements Serializable {

private Long id;

private String name;

private String description;

/**

* @hibernate.id column="id" generator-class="native"

public Long getId() {

return id;

}

/**

* @hibernate.property column="name" length="20"

public String getName() {

return name;

}

/**

* @hibernate.property column="description" length="64"

public String getDescription() {

return description;

}

…set method 省略…

}

使用Hibernate Plugin建立Table Schema

到目前為止我們設定了hibernatedoclet、建立了POJO的類別並自動產生了相關的Mapping file。假設這時資料庫Schema早已建立好的話，就可以開始使用Hibernate進行DAO的開發與測試了。倘若Schema尚未建立呢？需要自行建立嗎？而自行建立則又會引發另一個問題，POJO的設計是基於Schema所建立的。當日後Schema修改時也必須對應相關的POJO或Mapping file進行維護。一次、二次還可以接受，但在專案開發的過程中需求永遠在變化，很難保證Schema不會一直變更，一旦次數一多，將引發難以重構的災難。

在Ant中可以透過net.sf.hibernate.tool.hbm2ddl.SchemaExportTask協助我們將*.hbm.xml再次轉化成相對應資料庫的Schema，而在Maven上可以使用Hibernate Plugin協助進行SchemaExport。基於某些因素Hibernate Plugin最新版本為1.3並且已有一段時間沒有新版本釋出，該版本並未支援Hibernate 3.X，若讀者使用Hibernate 2開發的話，可以直接進行下載。在本次範例中我們將下載經過1.3版本修改的Hibernate Plugin1.4 (請讀者參考相關資源4進行下載)。

將[%MAVEN_HOME%/plugins]下的1.3版移除，放置下載完成的maven-hibernate-plugin-1.4.jar於該資料夾內即完成了hibernate plugin的安裝。接著參考設定 4在project.xml中加入相依套件，此處的設定中我們加入了maven-hibernate-plugin的設定與Hibernate進行SchemaExport時所需的套件，另外為了示範Hibernate跨資料庫平台的特色，在此引入而PostgreSql與Hsqldb二個開放原始碼資料庫的JDBC協助進行測試。

在進行SchemaExport功能時可以設定是否正式進行資料庫的更新，或者只是單純的產生資料庫Schema的文字檔供開發人員進行修改或使用。為此必須正確設定Hibernate與資料庫連結的相關參數，參考設定 5與設定 6比較範例中二種資料庫設定的異同處，而關於hibernate.dialect參數的設定，請參考Hibernate官方參考手冊。

最後參考設定 7加入Hibernate plugin所需的參數，讀者對照表 2即可知相關參數的意義為何。當設定完成後於Console下執行maven hibernate:schema-export即可進行SchemaExport，在此我們分別為了PostgreSql與Hsqldb作了SchemaExport，請參考圖 2與圖 3的結果。若讀者不希望直接進行資料庫的更新，則可將project.properties檔中參數maven.hibernate.text設為yes再次進行hibernate:schema-export，即可於[target/schema/schema.sql]檔中查看匯出的資料庫SQL語法。

hibernate:schema-export這個goal可以協助我們進行建立資料庫Schema，而當進行POJO的修改並重新產生Mapping file時，可運行maven hibernate:schema-update，該指令將可在不移除資料表的清況下進行資料庫Schema的更新，對於DataBase Schema的重構有很大的幫助。

設定 4 project.xml增添相依套件

<groupId>maven</groupId>

<artifactId>maven-hibernate-plugin</artifactId>

<type>plugin</type>

</dependency>

<groupId>postgresql</groupId>

<artifactId>postgresql</artifactId>

</dependency>

<groupId>hsqldb</groupId>

<artifactId>hsqldb</artifactId>

</dependency>

<groupId>geronimo-spec</groupId>

<artifactId>geronimo-spec-jta</artifactId>

</dependency>

<groupId>commons-lang</groupId>

<artifactId>commons-lang</artifactId>

</dependency>

<groupId>hibernate</groupId>

<artifactId>hibernate</artifactId>

</dependency>

設定 5 database-postgresql.properties

hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

hibernate.connection.url=jdbc:postgresql://localhost/demo

hibernate.connection.driver_class=org.postgresql.Driver

hibernate.connection.show_sql=true

hibernate.connection.username=test

hibernate.connection.password=test

設定 6 database-hsqldb.properties

hibernate.dialect=org.hibernate.dialect.HSQLDialect

hibernate.connection.url=jdbc:hsqldb:hsql://localhost/demo

hibernate.connection.driver_class=org.hsqldb.jdbcDriver

hibernate.connection.show_sql=true

hibernate.connection.username=sa

hibernate.connection.password=

設定 7 project.properties增添相關屬性設定

#####################################

# hibernate properties

#####################################

maven.hibernate.properties=${basedir}/database-postgresql.properties

#maven.hibernate.properties=${basedir}/database-hsqldb.properties

maven.hibernate.quiet=no

maven.hibernate.text=no

maven.hibernate.drop=no

maven.hibernate.delimiter=;

maven.hibernate.output.dir=${maven.build.dir}/schema

maven.hibernate.output.file=${maven.hibernate.output.dir}/schema.sql

表 2 maven-hibernate-plugin設定

參數	說明
maven.hibernate.properties	hibernate參數設定檔放置路徑，無論直接進行資料庫的更新或單純產出Schema的文字檔，皆必須要進行該項設定主要以hibernate.dialect參數決定使用何種資料庫方言。
maven.hibernate.text	若為yes則執行Schema Export時將直接匯出SQL成文字檔，並不會進行資料庫的更新，若設為no則直接進行資料庫Schema的更新，預設為no
maven.hibernate.quiet	是否顯示詳細的Schema Export資訊，例：當maven.hibernate.text=no，maven.hibernate.quiet=yes時，將直接進行資料庫Schema的更新，Console下不會顯示任何訊息，預設為yes
maven.hibernate.drop	是否只執行drop資料表的動作，若maven.hibernate.text=yes則匯出SQL檔將只包含drop table的SQL語法。
maven.hibernate.delimiter	分隔SQL Commands的定義符號，預設值為空字串，而大多數狀況使用”;”作為分隔符號。
maven.hibernate.output.dir	若maven.hibernate.text=yes，匯出檔放置資料夾，預設為${maven.build.dir}/schema
maven.hibernate.output.file	若maven.hibernate.text=yes，匯出檔放置路徑，預設為${maven.hibernate.output.dir}/${maven.final.name}-schema.sql

圖 2 PostgreSql SchemaExport結果

圖 3 Hsqldb SchemaExport結果

結論

Hibernate是一個開放原始碼的物件關聯映射技術，針對了JDBC進行了輕量化的將關聯資料轉化為物件封裝，使得開發人員可以隨心所欲的使用物件導向思維來駕馭資料庫。而在本期的介紹中我們了解了使用Maven協助Hibernate建立Domain Object的一種應用，而除了本次範例的方式外，Hibernate也可以使用Middlegen的方式透過現有的資料庫Schema產生出Mapping file，又或著從Mapping file建立出Schema與Java Domain Object。因此可依專案的狀況進行彈性的調整。

Hibernate的應用可以切入在任何使用JDBC的場合，既可以應用於單純的Java Application，也可以在Servlet/JSP的Web應用程式中使用，更可以應用在EJB的J2EE架構中取代CMP，完成資料持久化的重任。倘若更深入Hibernate的架構與觀念中，則將更了解物件關聯映射技術的最佳化實踐。

女孩！你是花朵還是大X

2007-08-03T19:10:00.000+08:00

女孩！你是花朵還是大X…
端看被你吸引來的是什麼而定。
如果被你吸引而來的是蝴蝶與蜜蜂，那麼你就是嬌豔欲滴的鮮花。
若圍繞在你身邊的只有蒼蠅，應該猜得到你是屬於什麼了。

所以，女孩呀！
呈現你的氣質、培養你的內涵、散發出令蒼蠅逃避蜜蜂喜愛的氣息。
你才是一朵真正的花，而蜜蜂、蝴蝶也將為你散播愛的花粉。

不過若被你吸引而來的蜜蜂、蝴蝶、蒼蠅，
你是一概接受並且一律通殺的話，
則你將只是看似甜蜜，實則佈滿陷阱，
等著獵物掉入的一株豬籠草而已。

(2006.05月號--148期)開放原始碼專案管理工具_建立專案與IDE環境設定

2007-07-29T19:14:00.000+08:00

在以往初步建立專案的過程中，多數傾向於二種方式，其一是依賴IDE，建立專案同時啟動專案精靈，顯示多個專案範本，藉由開發人員選擇範本的不同進行專案的初始化並建立符合需求的開發環境設定，並在IDE上進行建置、佈署、測試。這種方式的優點是方便、易學、無需了解複雜的環境配置即可進行。而缺點是受限於IDE的開發方式，只適用公司內部或單一公司實作的小型專案，也必須限制使用特定的IDE進行開發。對於大型或是多數委外進行開發的專案則不適用，因為我們無法強制委外的開發廠商使用統一的IDE進行開發。

其二是將專案建置邏輯撰寫於Ant 腳本中，由Ant協助進行程式碼的編譯、專案的佈署、單元測試、整合測試等的建置步驟。其優點是開發過程中完全不依賴IDE開發環境，因此在目前在大型的J2EE專案中幾乎都看的到Ant的蹤跡。而缺點是Ant的腳本並沒有一定的建置邏輯與規範，因此在目前業界中Ant腳本在各專案中可重覆使用的機率並不高，並且必須因應專案特性的不同而必須重寫或修改Ant的建置腳本，但在進行中大型專案裡維護Ant並不是件容易的事，而另一個缺點是Ant無法協助我們進行IDE環境的設定，因為充其量Ant只包含建置邏輯罷了。

在本期的內容中，筆者將為各位介紹Maven是如何協助我們從無到有建立出所需的專案開發環境，並且配合多個不同的IDE Plug-in協助我們建立Eclipse、JBuilder、IntelliJ IDEA等IDE開發環境的配置。

Maven Genapp Plugin

一般習慣使用IDE的開發人員，通常都是使用專案精靈工具，套用範本來建置專案。假若Maven專案的建置必須像Ant腳本一樣無中生有的自行撰寫的話，大概就不會有太多人嚐試用Maven進行開發了。而Maven Genapp Plugin如同專案精靈一樣，透過對話的方式，輔助我們建立新專案。

在開始實作之前，請先確認Maven環境中的Genapp Plugin的版本為何，但如何得知目前版本呢，可至[%MAVEN_HOME%/plugins]資料夾下查看是否有maven-genapp-plugin-x.x.jar或者在[${maven.home.local }/cache]下是否包含著maven-genapp-plugin-x.x的資料夾。我們可以從這二個地方即可得知目前版本訊息。至筆者截稿為止，版本為2.3，若讀者手上的版本稍舊的話，可透過執行maven plugin:download -DgroupId=maven -DartifactId=maven-genapp-plugin -Dversion=2.3進行下載更新。

為什麼要先確認Genapp的版本呢，其原因在於Maven在發展過程中有其建議的資料夾結構，參考資料結構 1，而在2.3之前版本中的專案範本，並沒有完全依照如此的資料夾結構進行設置。因此在建立出的專案中會與資料結構 1的格式稍有不同，但若不下載新版的maven-genapp-plugin也不影響往後專案的建置，因為Maven只建議開發人員，統一的資料夾結構對開發是有幫助的，若專案開發環境有自己的資料夾結構或是原先由Ant建置的專案欲移轉到Maven上進行開發，都可以依照專案原本的資料夾結構進行建置。

接下來參考圖 1執行maven genapp並依提示輸入，使用專案範本、專案根路徑名稱、專案ID、專案名稱、原始碼的Package名稱，當輸入完成後立即建置出所需的專案架構供開發人員進行下一步的開發。這樣的功能就如同IDE工具的專案精靈一樣方便，但有個問題，GenApp Plug-in究竟提供多少範本協助開發人員建置專案呢？這個部分可參考相關資源1的GenApp官方網站，另外也可以直接查看[${maven.home.local }/cache/maven-genapp-plugin-2.2/plugin-resources]資料夾清單，相關內容說明可參考表 1 。

到目前為止我們已經可以很輕鬆的建立起一個新專案，而且完全不相依於任何IDE。假若Maven能順便協助開發人員將IDE開發環境設定好那可就更完美了！那是當然的，接著筆者將介紹Maven IDE Plug-in的使用。

表 1 範本清單

範本名稱	範本說明
default	簡易的應用程式專案。
ejb	簡易的EJB專案。
struts	Web應用程式專案並且以Strust為MVC的架構。
struts-jstl	Web應用程式專案並且使用Strust與JSTL架構。
struts-validation	Web應用程式專案並且使用Strust與Validation架構。
tapestry	Web應用程式專案並且以Tapestry為MVC的架構。
web	簡易的Web應用程式專案。
web-jstl	簡易的Web應用程式專案並且使用JSTL。
web-velocity	Web應用程式專案並且以Velocity為MVC的架構。
complex	建立一個複雜的J2EE專案，產生multiproject架構。

資料結構 1 Maven建議資料夾結構

+- src/ --專案相關代碼路徑

| +- main/ --主要程式碼路徑

| | +- java/ --java原始碼路徑

| | | +- ...

| | +- resources/ --所需資源與設定路徑

| | +- ...

| +- test/ --測試程式碼路徑

| | +- java/ --java測試原始碼路徑

| | | +- ...

| | +- resources/ --測試用資源與設定路徑

| | +- ...

| +- site/ --建立專案站台設定路徑

| +- xdoc/

| +- ...

+- target/ --專案建置成品放置

| +- ... 與其他建置中暫存路徑

+- project.xml --POM設定檔

+- README.txt

+- LICENSE.txt

圖 1 Maven Genapp

Maven Eclipse Plugin

透過圖 1的操作我們已經建立好套用web範本的MyWebApp專案，接著進入建立好的MyWebApp資料夾中並執行maven eclipse，這時Maven將協助開發人員建立Eclipse的開發環境設定。

當產生出環境設定之後，啟動Eclipse並於功能表中執行[File][Import…]，進入匯入專案作業。在對話視窗中選擇[Existing Projects into Workspace]進行下一步，接著在對話框中[Select root directory:]選項執行[Browse]，並指向產生專案的路徑[D:DevMyWebApp]，最後按下[Finish]即可。

第一次在Eclipse中匯入Maven建立的專案時，Eclipse的[Problems]標籤將會判斷出多項錯誤，分別是[The project cannot be built until build path errors are resolved]與多個[Unbound classpath variable: 'MAVEN_REPO/xxxx/jars/xxxx-xx.xx.jar' in project MyWebApp MyWebApp]。這些錯誤的原因在於Maven使用了MAVEN_REPO參數設定相關JAR檔的關聯，而Eclipse開發環境中尚未設定該參數所致。

解決方式有二種，其一執行[maven eclipse:add-maven-repo -Dmaven.eclipse.workspace=%WORKSPACE_PATH%]可透過Maven Eclipse Plugin進行MAVEN_REPO的參數設定至[%WORKSPACE_PATH%]指定的workspace路徑下。執行完成後，必須重新啟動Eclipse才會生效。

其二可參考圖 2直接在Eclipse功能表中點選[Window][Preferences]，在對話視窗中選擇[Java][Build Path][Classpath Variables]進行Classpath參數的設定，新增MAVEN_REPO參數，並將路徑指向[${maven.home.local }/repository]下即可。Maven預設repository的路徑指向[C:Documents and Settings%登入帳號%.mavenrepository]。

當完成設定後Eclipse將依目前設定重新建置專案，結果如圖 3所示，這時之前的錯誤訊息將不會再出現。因此日後在專案開發的過程中當我們修改過project.xml的POM設定或者新增、移除JAR的的相依關聯性時，只需再次執行maven eclipse就可依project.xml的設定重新產生相符的Eclipse開發環境配置。如此的Plugin不管在那個專案中都非常方便。

圖 2 設定Eclipse MAVEN_REPO參數

圖 3 開啟專案的Eclipse IDE

Maven JBuilder Plugin

目前業界進行J2EE專案開發最常用的IDE，除了Eclipse之外我想另一個廣受歡迎的就是JBuilder吧。在此也不避諱的為各位介紹一下如何使用Maven JBuilder Plugin協助我們建立環境設定。

在此我們直接執行maven jbuilder，若無意外的話將會看到BUILD SUCCESSFUL的訊息並且產生本範例中的[D:DevMyWebAppMyWebApp.jpx]的環境設定檔，但若發生BUILD FAILED的狀況的話，筆者大概可以猜測出讀者應該使用的是2005與2006的JBuilder版本。

其原因在於截至目前為止，Maven JBuilder Plugin的版本為1.5，在目前的版本中預設並未支援JBuiler2005之後的版本設定。但若是因為如此而造成JBuilder的愛用者對Maven興趣缺缺的話，那可就是筆者的罪過了。

雖然預設的Plugin尚未支援新版的JBuilder，但只需進行小部分修正即可排除這個問題。首先至[${maven.home.local }/cache/maven-jbuilder-plugin-1.5]路徑下開啟plugin.jelly檔案，在檔案開頭附近很容易可以找到有一行的設定如[value=".jbuilderX,.jbuilder9,.jbuilder8,...]將其修改為[value=".jbuilder2005,.jbuilderX,.jbuilder9,.jbuilder8,...]參考設定 1，存檔後再次執行maven jbuilder即可。

這時我們將會發現Maven JBuilder Plugin正確無誤執行完成，也就是說事實上JBuilder每一個不同版本在安裝時會將相關設定檔存放至UserHome下，例如JBuilder2005存放路徑為[C:Documents and Settings%登入帳號%.jbuilder2005]，因此我們只需將設定的版本名稱加入plugin.jelly中就可使Maven JBuilder Plugin支援該版本。

接著只要在JBuilder中執行[Open Project…]開啟由Maven產生的MyWebApp.jpx，無需調整任何設定即可進行專案開發，參考圖 4。

設定 1 maven-jbuilder-plugin-1.5/plugin.jelly

<goal name="jbuilder"

description="Generate JBuilder project files"

prereqs="jbuilder:generate-library, jbuilder:generate-project"/>

<def:taglib uri="jbuilder">

…中間省略…

<def:tag name="getDefaultProject">

<j:set var="jbuilderDirs" value=".jbuilder2005,.jbuilderX,.jbuilder9,.jbuilder8,.jbuilder7,.jbuilder6,.jbuilder5,.jbuilder4,.jbuilder" />

<j:set var="${userHome}" value="null" scope="parent"/>

…以下省略…

圖 4 開啟專案的JBuilder IDE

Maven IDEA Plugin

介紹完二個主流IDE的設定之後，我們來看一下一個鮮為人知，但功能卻不俗的IDE開發工具IntelliJ IDEA，IDEA無需像Eclipse必須自行加上一堆Plugin之後才能達到較完善的開發環境要求，預設的IDEA環境非常的友善，上手非常容易，並且相似於Eclipse，網路上有眾多的Plugin支援IDEA。另外在所有的IDE開發工具中IDEA擁有最強的Refactor功能，方便開發人員進行重構。

Maven IDEA Plugin可以協助建立IDEA開發環境，但必須注意到目前IDEA Plugin版本為1.6，若讀者系統中的版本較舊，可透過執行[maven plugin:download -DgroupId=maven -DartifactId=maven-idea-plugin -Dversion=1.6]進行下載。

執行maven idea後，啟動IDEA進行[Open Project…]開啟由Maven產生的MyWebApp.ipr無需調整任何設定即可進行專案開發，參考圖 5。

圖 5 開啟專案的IntelliJ IDEA IDE

結語

在本期中介紹了如何使用Maven起始一個專案的建置，也了解了如何透過IDE Plugin將Maven的專案導到各個主流的IDE開發環境中進行協同開發，從這些實作中我們了解到，Maven並不會在開發中完全取代IDE或者限制使用特定IDE，而是以一種通用的專案建置方式協助每一個專案的進行。開發人員可以使用任何方便的IDE工具進行開發，而專案的建置、管理、測試、佈署等，一切的一切交給Maven就搞定了。

太平山旅遊規劃參考

2007-07-28T12:32:00.000+08:00

最近，朋友們正在計劃九月份要到宜蘭的太平山一遊，雖然我不是主辦人，不過我想，先整理一下相關資訊，定一些小小的計劃，也許可以幫助我這些朋友們先了解一下要去那裡玩、有什麼景點、可以住什麼地方等訊息。才不會到時又是臨時慌慌張張的出發，路上才再找地圖，到定點後又不曉得該從那玩起的窘境。

宜蘭，應該算是我滿有回憶的地方，曾經在羅東醫院駐點過一陣子(看清楚，是駐點、不是住院)，遺憾的到是沒真正好好看過宜蘭這個地方，只有在羅東夜市逛過幾回，運動公園則是當時要將機車騎回台北前匆匆繞了一下。沒真正看過這個好山好水的好地方，當然啦！太平山，在回憶中也只是個傳說中的地方而已。

參考資料：

http://tps.forest.gov.tw/

http://www.ilantravel.com.tw/taping/

http://www.tai-ping-shan.com.tw/index1.htm

http://recreate.forest.gov.tw/forest.php?init=05&char=big5&forest=1

http://www.storegood.com/place/a.php

http://yilan.emmm.tw/index_m.php?ptype=ieb_c&L3_id=32523

Blog的介紹：

http://tw.myblog.yahoo.com/jw!9vMUZySZFRTLaCWDXjW2/article?mid=4431&prev=4483&next=-1

http://www.wretch.cc/blog/wus2121&article_id=6767096

某某旅行社二天一夜自由行的優惠：

http://www.tai-ping-shan.com.tw/ontravel/boarddetail.asp?bid=34

不過上面只列出、二人成行或三人成行的方案。

若是人數較多的話，可能得先問問看。

如何到太平山

方式一：自行開車

台北→國道5號北宜高速公路→下頭城交流道左轉接台9線省道直行→右轉省道7號→省道7甲號→左轉接太平林道→仁澤→太平山森林遊樂區。

交通時間：從國光客運到太平山時間為2時30分來推的話，從台北到宜蘭保守估計時間為1時30分的話，猜測完整的行車時間最保守為4個小時左右(參考下圖)。

但有資訊說從宜蘭到太平山約100分鐘，若行程順利的話假設從台北到宜蘭為1小時的話，則行程約為2小時40分左右。

方式二：大眾交通工具

像之前去阿里山看到的一樣，也有客運公司直接開上太平山的。但這種旅行方式得非常注意時間的安排。

搭國光汽車客運：每週星期六、日開於宜蘭或羅東搭車可直達發車時間為早上09:20分。行車時間約2時30分，每日往返一班，返回時間 (太平山站出發)下午15:30往宜蘭，宜蘭站電話03-9365441，羅東站電話03-9542054。

住宿資訊

直接參考：http://www.ilantravel.com.tw/taping/content/stay.htm

列了滿多住宿資訊的，從某些網站的討論區中得知，通常首選都是太平山莊，但也是最難訂到房的。

入園資訊

由土場（0ｋ+ 800、海拔300公尺）進入

為太平山出入門戶，「土場」是林業用語中的木材聚集地或卸材場地，它過去是太平山木材轉運站，也是平地森林火車的起點，旁邊停車場則為過去卸材場。

現在土場收費站已由原來的車站改成太平山國家森林遊樂區售票站，遊客須由此購票進入遊樂區，附近規劃停車場及森林小火車等景觀展示。

入園門票:

※ 假日全票：200元。半票：100元（軍警、學生請憑証購票)。

※ 非假日：全票：150元。半票：100元（軍警、學生請憑証購票)。

※ 團體票：全票：150元（20人以上團體，不含半票及優待票）。半票：100元。

※ 優待票：10元（65歲以上、115公分以下兒童及殘障人士，請憑證購票）。

※ 停車費 : 大、小型車各100元，機車20元。

管制時間：

每週六、日：AM 4:00~PM 9:00

寒暑假：AM 3:30~PM 9:00

非假日：AM 6:00~PM 9:00

遊客注意事項:

1.太平山氣溫比平地約低10度，

請自備禦寒衣物。

2.為行走步道請自備步鞋。

3.宜蘭市至太平山車程約100分鐘

，太平山距最近加油站約43公

里(為台7甲線101k處之大同加

油站)，請注意車油量。

急難通報電話:

1.太平山救難小組:03-9809806、9809603、9809618

2.太平山派出所:03-9809802 土場派出所:03-9809612

3.省立宜蘭醫院:03-9325192 羅東聖母醫院:03-9544106

博愛醫院:03-9543131

遊樂景點介紹

參考：

http://www.tai-ping-shan.com.tw/taiping/taiping.htm

http://tps.forest.gov.tw/scenic.html

http://www.ilantravel.com.tw/taping/content/info.htm

http://recreate.forest.gov.tw/forest.php?init=05&char=big5&forest=1

先看幾個小片段了解一下太平山吧！

民視－台灣之美系列3－宜蘭太平山篇

20070617_台灣之旅宜蘭太平山

travel video

健酪乳酸飲料-步道篇(宜蘭太平山)

補07/20~07/23 提前的父親節

2007-07-25T12:20:00.000+08:00

原先談定今天開始的顧問工作，因客戶端的流程關係，延後一周進行。
多了一些緩衝時間，當星期四知道消息後，想了一下，當下就決定了隔天就回中部一趟吧。

20號一早起床後收拾了行李後就出門了，搭上10:48AM的火車返鄉。
這班車是海線的，約在新竹、苗粟的途中看得到海岸線，稍微留意一下也可以看到台電的風力發電設備。就是那造價似乎有一、二億的大風車。不過若比海岸線的話，我是覺得東部的沿線的海景是比較好看的。突然間就想到了當兵時從東部花蓮搭火車返鄉的事了。

雖然這次回家是坐復興號，不過並不是尖峰時間，坐位很空，也沒誤點。(呵呵，如果以後回家都是如此的話，就真的太好了。)到達田中火車站後，已經是下午2:30分左右。下車後直接往附近的某個攤販走去。為了買煎包等了約莫20分鐘吧(記得某次回來時吃過，覺得不錯吃，這次一次買了很多，多的當明天早餐)。接著就一路往回家的路上走了(有不良的示範，肚子太餓了，邊走邊吃)。

此次返鄉主要是要提前過「父親節」，我們家是沒那麼重視節日啦！不過我還是希望回家一趟，跟老爸說聲，辛苦囉！我已經忘了，不知從什麼時候開始，除了過年會包個大紅包外。母親節、父親節，我也會另外再包個大紅包(記得某一年，我好像連三節都包了)。以前曾經打算要買好一點的按摩椅給爸媽，不過老人家就是一直不要。所以囉大都折合現金，給老人家們開開心。給了老爸紅包時，爸愣了一下，我才跟老爸表明，八月份會較忙，所以次是回來過父親節的。
所以就開心的收下吧！

六、日除了中午、晚上跟家人閒話家常外，幾乎都在趕之後上課要用的簡報檔(還是不得閒)。不過在家的感覺總是好的，多一個人就多了點熱鬧，跟自己一個人在台北寂寞到在家待不住的感覺是不一樣的。

23號星期一，回板橋的時候到了，雖然還想多待幾天，不過在外生活久了，認床認的嚴重。在家通常失眠的情況特別明顯，回北部吧，給自己的期望，還有很多事要完成呢！

補07/18 探望準媽媽

2007-07-19T11:14:00.000+08:00

今早到客戶那，從板橋騎車到內湖，乖乖…好遠呀！
又是上班尖峰時間，摩托車就像擠沙丁魚一樣，一路擠到內湖去。

今天要進行的是之前銀行專案的權限控管系統的技術交接工作。
一點多左右到中山與民權交叉路的Starbucks與Krilo聊了一下工作的相關事宜。
之後就接到菀公打來的電話。想了想今天預定的事大致上已經完成。
只剩下整理思緒與聯絡通知相關人員工作與付款事項。
好，去菀公家串串門子吧！

從菀公口中得知朋友嬌嬌，似乎有些狀況進了醫院。
提議去探望一下，看看這位準媽媽的情況如何。

聽說是前幾天身體不適，醫生檢查後請他立刻住院
(原因是什麼嬌嬌有說，不過男人嘛，
很難理解出如何將，女人、孩子與肚子的狀況用言語作解釋。)
當我們二個大男人看到她時，她手上正打著安胎針。
據他說每隔幾小時就會有醫生、護士替他裝上儀器作診斷。
若肚中小孩心跳或子宮收縮發生不穩定的狀況的話，
就必須立刻開刀，也就是說小Baby可能得提早出來看看世界了。

菀公之前提說嬌嬌已經有像是個媽媽的樣子了，
整個人都散發了母親的光輝，前陣子幫忙搬家時到還沒刻意注意到。
今兒個一看，真是，連我都想叫他聲媽了呢！

我們三人天南地北聊了很多，包括有醫生請他住院時他想先梳洗一下，
因為小孩出生後得忍到做月子完後才能洗頭；
懷孕像帶著球的感覺有多不舒服，生活作息有多不方便；
女人生產、做月子時男人可得大方點，儘量讓老婆開心、舒服，不然可會被老婆唸一輩子…等。
看來這位準媽媽已經開始有了媽媽經了呢。

嬌嬌，這位堅強的媽媽，加油囉！

介助犬武藏

2007-07-12T23:14:00.000+08:00

剛做完一份要上課用的簡報，也恰好第四台的線路似乎出了狀況。
因此就看了最近到手的日劇SP，「介助犬武藏，上學去吧！」
劇情是什麼看倌們自已找找吧！
有耐心的人可以連上土豆網
http://www.tudou.com/playlist/id/1006009/
在線的收看。雖然是老樣子的Patterns，不過對於這方面的故事。
我還是滿喜歡的，至少滴下幾滴淚，舒緩一下乾眼的症狀。
這裏面有一段話說得還不錯：

有一首被世人傳唱的作者不詳的古詩「狗的述懷」
在那首詩裏和狗一起生活過的人們一直和狗用心交流著。
「我的一生，肯定不是漫長的。
就算只是很短的時間，我也不想和你分離。
請不時的和我說說話，就算言語不通，你的心意我也能領會。
請相信我，那就是我的幸福。

當我開始最後旅程的時候，請陪在我的身邊。
只要你在我身邊，我就能戰勝一切。

然後，請不要忘記…
我一直愛著你。」

Maven2 Report使用javancss-maven-plugin

2007-07-11T19:56:00.000+08:00

簡介一下Maven2中javancss-maven-plugin進行Report的使用。

更詳細的用法請參考：http://mojo.codehaus.org/javancss-maven-plugin/index.html

簡易使用法：

基本上只要在reporting標籤中使用進行plugin的設定即可。之後在執行maven site時就會產生javancss的報表資料。

</plugins>

<groupId>org.codehaus.mojo</groupId>

<artifactId>javancss-maven-plugin</artifactId>

</plugin>

</plugins>

</reporting>

較複雜的使用法：

雖然設定簡單，但目前這個plugin還不是很穩定，不穩定的原因大多出現在中文問題上。

Javancss會針對*.java檔中的註解與非註解進行分析處理，但在使用”//”註解型式中包含中文的話，偶爾會發生無法進行完整分析的狀況，通常使用”/**/”來進行註解的話大多能解決問題，但若是還無法順利產生javancss報表的話，可以透過自行設定那些檔要引入進行處理，那些檔要排除分析來處理，不過中文問題通常是在Windows系統發生的，Linux似乎就沒有這個狀況。

</plugins>

<groupId>org.codehaus.mojo</groupId>

<artifactId>javancss-maven-plugin</artifactId>

</includes>

<exclude>**/LdapManager.java</exclude>

<exclude>**/Pending.java</exclude>

<exclude>**/AuthManager.java</exclude>

<exclude>**/BusTypeController.java</exclude>

<exclude>**/SetAuthorityController.java</exclude>

</excludes>

</configuration>

</plugin>

</plugins>

</reporting>

Maven2 Report使用maven-javadoc-plugin

2007-07-11T19:53:00.000+08:00

簡介一下Maven2中maven-javadoc-plugin進行Report的使用。

更詳細的用法請參考：http://maven.apache.org/plugins/maven-javadoc-plugin/

簡易使用法：

基本上只要在reporting標籤中使用進行plugin的設定即可。之後在執行maven site時就會產生javadoc的文件資料。

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-javadoc-plugin</artifactId>

</plugin>

</plugins>

</reporting>

較複雜的使用法：

一般而言使用簡易的方式即可，但總有某些時候會出問題。

l 狀況一：
系統是使用MS950編碼的系統，但java程式卻是用UTF-8
解法：使用encoding標籤，指定*.java檔是使用何種編碼。

l 狀況二：
產生的javadoc api文件，但開啟後卻是亂碼(必須在瀏覽器中指定編碼後才正常)
解法：使用charset標籤，指定在網頁上是使用何種編碼。

l 狀況三：
某些*.java檔javadoclet撰寫有問題，導致無法順利產生JavaDoc API文件。
或者某些*.java文件並不想產生相關的java api文件時。
解法：使用excludePackageNames標籤，排除不希望產生api的package。

l 狀況四：
除了javadoclet預設的@parameter外，希望自行定義的@parameter資訊也能顯示於Java Doc API中。
解法：使用tags標籤，在其中指定tag的name、placement、head屬性即可。

<groupId>org.apache.maven.plugins</groupId>

<artifactId>maven-javadoc-plugin</artifactId>

<excludePackageNames>org.*:arch.common.*</excludePackageNames>

<tags>

<tag>

<name>hibernate.id</name>

<head>To do something:</head>

</tag>

</tags>

</configuration>

</plugin>

</plugins>

</reporting>

自行車旅遊規劃

2007-07-08T22:28:00.000+08:00

參考網址：http://tour.tpc.gov.tw/bicycle/index.htm

菀公同學聽說在「台北縣工商展覽中心」又開始了特賣會的活動，相約一起去敗家一下。
因為上次戰果豐富，所以這次當然捨命陪君子囉。

會後聽他說他們一起進修的同學大家畢了業，卻捨不得同窗的情誼，打算辦一場「自行車之旅」再一次攏絡同學之間的感情。
，聽說同學們二話不說一致推舉菀公為主辦人。為此我們到了「二重疏洪運動公園」的自行車租借處了解一下自行車的租借狀況。
上面的圖是當時拍下來的。打算由二重或其他地點出發，目標可能為八里左岸或淡水。所以必須考量是甲地借車，乙地還車的方式。
上面是費率表囉！

我想菀公，建議你利用一下我部落格的方便性。
以回覆這篇文章的方式進行你們同學之間的討論。
其他同學就可以直接在這一篇文章中得知討論的結果了。
呵呵！當然一定程度上也可幫我衝衝人氣囉！

補7月7日-兩個宅男的聚會與再一次的「變形」

2007-07-08T22:04:00.000+08:00

力特的前同事，大枯兄聽說「變形金剛」的票房超賣座，又經由我之前的慫恿所以決定要看這部片。

果然在「國賓」戲院看的感受不同，大戲院就是有大戲院的好…音效超讚、震撼力夠，而且觀眾笑聲出現的頻率多了好幾倍，前一次來國賓是跟力特其他同事一起來當然大枯兄也在內，他說，上一次看「史瑞克3」片長一個小時半左右。感覺還好，不過今次的「變形金剛」片長143分鐘，也就是二個小時23分。加上特效、內容、搞笑程度超讚有種值回票價的感覺。

上次在「今日」看「變形金剛」最後還有小部分沒看到，這次我就提醒了大枯說，等會完結時再坐一下，還有一小段，最後我們看到，最終還有留下伏筆，還記得狂派的「天王星」的戰鬥機變形機械人嗎？在片中並沒有掛點，最後一幕中他飛走了。而其他狂派全部被丟入世界最深的海溝中。因此有拍第二集的可能…呵呵！期待。

今天的大枯兄雖然保持著以往的開朗，但看得出有些疑慮，需要朋友們開導開導，給他點意見。當然還是工作上的啦！不過問題不大，只是他必須做出抉擇而已。
在此預祝大枯兄一切順利囉！九月份後我們再來聊聊各自的發展吧！加油囉！

敏捷開發的比喻

2007-07-05T10:53:00.000+08:00

書摘：O'Reilly軟體預先架構之美學 (Prefactoring)

敏捷開發(Agile development)很像輕裝健行。輕裝健行者攜帶的裝備比平常健行者少很多。因此，他們可以走得比較快，花的精力也較少。

輕裝健行者也比平常健行者更有經驗。他們只帶必要配備，也就是完成旅程必要的東西。技巧、知識和經驗則完成了整個圖像。他們知道怎麼以最簡便的遮蓋物紮營取暖。他們知道上哪找水，所以他們只帶少量的水。

要當極致輕裝健行者，那可是需要不少技巧和經驗。某人必須能夠利用大自然的材料做出必要的東西。

另方面，重裝健行者會覺得他們必須帶上所有必要裝備，以應付他們可能碰上的任何情況。他們的裝備給了他們安全，然而，也會讓他們慢下來。

(2007.6月號－161期)_持續性整合開發導論(下)

2007-07-01T23:44:00.000+08:00

持續性整合的實踐：選用合適的CI伺服器

持續性整合開發可不是有了專案建置工具與貫徹測試優先原則就沒事了。要記住現在不是單打獨鬥的時代，講求團隊合作，因此不論是公司內參與的開發人員或者外部協同合作的廠商，都會對開發的成果產生重大的影響，因此如何即時掌握專案整體的開發狀況就是另一項挑戰。

Continuous Integration Server又稱CI伺服器，就是用來管理協同開發的持續性整合工具，目前常見的有：

CruiseControl：Java社群中老字號的CI工具，擁有完整的CI所需功能。
Continuum：為Maven的子專案，算是後起之秀，設定方便為其優點。

CruiseControl它於2001年發佈已經有五年多的歷史，在許多方面，CruiseControl 伺服器已經成爲持續整合的同義詞，完善的對大多數版本控制伺服器的支援並方便進行擴充，安裝容易也是其優點，如果硬要說個缺點的話就是CruiseControl對於專案持續性整合是基於XML的設定，非常靈活而且彈性，但對不熟悉的人來說，有點困難，包含的Web的管理介面，對於專案的掌控來說非常方便。

Continuum於2005年發佈是最新的CI 伺服器之一，支援Ant、Maven1、Maven2與Shell進行專案的建置，也支援了大多數的版本控制伺服器，同CruiseControl一樣也擁有Web管理介面，並且可直接在Web介面上進行CI伺服器的設定，相對於CruiseControl來說比較方便，但以靈活度與擴展性來說，就比較差了，且因為推出時間較短，某些功能還不齊全。

到此我們可知完整的持續性整合開發環境至少必須架設版本控制伺服器與持續性整合伺服器，參考圖 1所示，開發人員與協力廠商開發平台持續對版本控制伺服器提交修改完成的程式碼，而通常在提交前會先取得目前最新的原始碼進行測試，當確認不影響版本控制伺服器上的原始碼後才進行提交。持續性整合伺服器可設定特定時間，當發現原始碼已經發生變化時，執行取得原始碼動作，並進行編譯與測試，此時將可完整的知道目前開發專案的穩定狀態，可設定持續性整合伺服器當專案建置成功或失敗時通知相關人員即時進行問題排除。

通常在CI伺服器發生建置失敗的原因，除了一般的程式碼錯誤外，開發人員未提交所有程式碼檔案或未解決程式碼衝突就提交也是原因之一，前者是開發人員針對多個原始碼檔案進行了修改，但因經過了一段時間，已經不確定到底有那些檔案需要提交而造成的問題。後者是當程式碼在版本控制伺服器上同一個時間有多個開發人員進行了修改，後者提交時會提示發生了檔案衝突，而開發人員未解決重覆提交產生的問題。這些問題的發生事實上都是開發人員對版本控制觀念的認知不足所致。無論取得或提交原始碼時需對整個專案進行，才不會遺漏掉必須提交的檔案。版本衝突時相對於版本控制系統都會有一套解決衝突的流程，只要小心都能避免。

圖 1 持續性整合開發環境

持續性整合的分析：產生可供評估的報表

開發過程中文件的產生是很重要的事，開發前期的系統分析、系統設計文件，開發中的原始碼進度與狀況追蹤報表，開發後期的元件使用手冊、系統操作手冊，無論是任何一份文件都是目前專案開發所需要的重要參考。但傳統軟體專案的開發多數文件的產生都是由人手工去撰寫的，若要在開發人員在開發過程中還必須挪出時間進行文件的撰寫，對於開發人員來說是非常痛苦的事。

更重要的是，開發過程中程式碼會變，所產出的文件當程式碼一改變可能沒多久就過時了。因此在業界有多數狀況都是專案開發前期非常認真的撰寫相關文件，開發中期發現文件內容跟不上程式碼的變化索性就暫時放一邊，打算等之後再統一寫，到了開發後期要不就是因為專案的Delay或失敗而成為一個沒有文件的專案，就是根本忘了到底新增了那些功能而成為一份殘缺不全的文件。

因此在多數的敏捷開發原則中就提出了，最好的文件就是原始碼，首先為了讓原始碼在日後維護容易，必須在撰寫程式碼時保持程式碼的可讀性，並且必須統一程式碼的風格，訂定統一的開發規範，在一定程度上降低對文件的依賴，另外透過在程式碼中順手加上的文件資訊也就是所謂的Java Doclet的註解型式，配合相關的Doclet工具，就可隨時產生符合當時狀況的Java Doc說明文件。

為了追蹤專案開發進度與協助程式碼進行分析與重構，在此列出常用的持續性整合開發程式碼分析工具：

CheckStyle：檢查程式碼撰寫風格是否符合規範。
PMD：靜態程式碼分析工具，可用於找出潛在錯誤程式。
JavaNCSS：協助在開發過程中檢查出程式碼的複雜度。
Cobertura：於執行期檢查執行與未執行程式的測試覆蓋率檢測工具。

CheckStyle是自動化程式碼風格檢查工具，在傳統的多人協同開發中，可以發現每位開發人員都有相異的程式碼風格，少數有經驗的開發人員在風格上都有一定程度的好習慣，但在程度參差不齊的參與者中，很難保證有一致的Code Style，CheckStyle工具設定了一份規則文件，於建置時期對程式碼進行檢查，將不符合規範的資訊列出，因此開發人員可透過這份資訊了解本身所撰寫的風格是否合乎需求，並進行改進。如此一來維護程式碼就變成一件容易的事，畢竟誰都不想維護一份有怪異風格的程式碼。參考圖 2所示的CheckStyle報表，提供了Info、Warning、與Error的訊息，並緊接著列出錯誤原因與行數。

PMD是一個Java原始碼分析工具，透過一系列的規則比較可以協助找出潛在的Bug，包含 16 個規則集合，涵蓋了所有 Java經常發生的問題，如不良的命名規則、無用而未移除的程式碼、藕合度分析、不良的異常使用…等。在此我們參考圖 3可看出，該PMD報告說明了有40個檔案找到了65個錯誤，並且列出了錯誤原因為import了未使用的類別，還有包含了一個空的Exception區塊。由此一來開發人員可移除無用的import而不會造成日後不使用相關jar檔後造成的編譯錯誤，處理Exception區塊以避免日後發生問題後無法得知究竟異常原因為何。當然除了PMD所內建的檢查機制都可以因專案的需求進行修改，並可自行撰寫新的規則。

JavaNCSS用於進行原始碼的複雜度分析，NCSS是Non Commenting Source Statements也就是分析非註解的原始碼資訊，聽起來似乎沒什麼但實際上JavaNCSS首先幫我們列出了前30名程式碼行數最多的類別，其次列出了前30名Method最多的類別，供開發人員分析是否包含了過多無用的程式碼或者該類別給予了太多的責任，由此進行重構的考量。另外最重要的部分列出了前30名Method的NCSS資訊，通常當Method中的程式碼行數過長，相對的也代表了有較高的NCC，NCC所指的是Cyclomatic Complexity Number意指為程式的複雜度，在Method中NCC愈高，事實上就愈不利於日後的維護，因此NCC的數值將是重構的重要依據。參考圖 4。

Cobertura是西班牙語覆蓋的意思，這個工具可以協助在進行單元測試的過程中統計已測試過的類別與未測試過類別的資訊，參考圖 5中明顯可知，當測試覆蓋率到達100%時也就代表了該類別中所有功能都至少被完整執行過1次以上，而覆蓋率分為Line Coverage與Branch Coverage代表著一般程式碼與有分支判斷的程式碼(例如：if else、switch或迴圈等)，當然分支愈多代表著該類別的複雜度愈高，撰寫高覆蓋率的測試程式碼就愈困難。在進行程式碼開發的過程中如何撰寫功能強大、程式複雜度低而高測試覆蓋率的系統是每位開發人員的理想，而透過工具的分析，可讓開發人員的理想更趨近於真實。

圖 2 CheckStyle報表。

圖 3 PMD報表。

圖 4 JavaNCSS報表。

圖 5 Cobertura報表

結論

持續性整合開發為專案帶來了高效率、可控管、靈活有彈性的開發方式，透過專案管理與建置工具的協助，能夠很輕鬆在專案編譯過程中產生所需的專案開發資訊與分析報表，這一切的一切都是自動化的。透過報表資訊的產出可以減少開發人員手工檢查的時間，帶來了更高的效率與生產力，透過持續性整合伺服器的快速回饋，可以即時掌握目前專案原始碼開發狀況，徹底解決了企業及大型專案協同開發的管理問題。記住所有專案的開發都會發生問題，但持續性整合開發能在專案進行過程中持續發現並盡速解決問題，在開發的每一步降低風險，要知道愈晚發生問題所衍生的維護成本會是早期發現的十倍甚至百倍。

作者介紹

盧建州 <jazz.lu0827@gmail.com>

有多年軟體開發經驗，注重軟體工程並善用Design Patterns。專研於Java、Open Source解決方案、跨平台技術與其異質資訊系統整合。目前為自由工作者。

上帝的安排

2007-07-01T23:35:00.000+08:00

上帝給每個人都有了絕佳的安排。
了解並且利用的人認為…上帝是眷顧我的！
誤解而且自怨自艾的人認為…上帝遺棄我了！

要知道
出現難題就代表了要換個方式思考…
情況不如預期也許才是最好的安排…

反而一切若順利到不可思議的地步時…
也許你只要再往前踏一步，就會掉入無可回天的深淵。

接下來的兩個月

2007-07-01T23:27:00.000+08:00

兩個星期了吧!端午節過後我就讓自己處於放鬆的狀態,因為我知道剩下兩個月的時間必須要開始精實了, 雖然這些日子多多少少都在接觸一些工作，但我認為還沒真正做出個自己要的東西。

不過並非代表又要進入一個從頭開始的階段,所意謂的是之前的我已經做好了準備工作,接下來該是將這些觀念、架構、邏輯與元件進行總整理,將其轉化為武器、防具與兵法守則來裝備在身,而在未來的日子裏將協助我攻城略地,所到之處將攻無不克、戰無不勝。

收心操:不看會後悔的「Transformers(變形金剛)」

2007-07-01T23:21:00.000+08:00

明天要收心認真了,但總覺得還沒休息夠,大概是玩心一起就很難收了吧!
昨晚一想，給自己再放縱一次就收心。
嗯！那就去看之前一直想看的那部片吧！今早約莫11點左右到了西門町，想都沒想就往國賓戲院走了去，
前幾天在網上看「變形金剛」場場客滿，總覺得不太相信，記得前陣子跟力特的朋友來看「史瑞客3」時，一樣也是
假日，人就沒有很多，也沒什麼人在排隊。不過今天一看，哇塞！人超多…要排到什麼時候呀？前次來沒看到，今天到是滿多人在賣黃牛票的。
用目光稍微掃了一下之後就給他放棄了，因為我不太想跟一大堆人擠。

轉向朝捐血車的地方前進(前幾天捐血中心發通知可以再捐了)，第二個狀況出現，哇咧…下午一點後才開放捐血。
正當覺得今天西門町是白來的正準備打道回府的時候，耶！我發現對面的今日影城也有上映「Transformers」。
問了賣票美眉後，當下決定就在這看這部片吧，利用了點開場前的時間到附近的誠品逛了一下，預先挑了幾本書，
預計等電影看完、捐完血後再過來買。

電影開場了，老實說…遠遠超過我的想像…，網路上看過的人提出的感想並不誇張…，有人說特效超讚、劇情緊湊沒有冷場。
有人說這部片非常搞笑，女生也非常適合來看，聽說劇場中女生笑的比男生大聲。而多數人都說，有機會會再看一次，
更有人身體力行已經看過二次以上了。

當時看到"搞笑"二字，怪！這不是科幻片嗎？好像從沒看到科幻片有搞笑的劇情，今天一看…呵呵！的確…一定程度上應該算喜劇哦！
超喜歡大黃蜂那部跑車假裝拋錨時，使用收音機刻意製造出浪漫的氣氛，當女孩打算自已走路回家時，跑車迅速發動，收音機傳出
"Baby come Back..."這首歌，呵呵！真希望能有一部這麼懂主人心意的車呀！

沒想到今天換個方向走，就會有不同的巧妙安排「看電影」Check、「捐血」Check、「買書」Check…今天做了三件事了呢！
不過我想唯一美中不足的就是，沒進到「國賓」感受那音響的震撼力…說真的，我也希望再看一次「Transformers」但下次一定得在國賓看。

聰明的男人、女人與傻男女

2007-06-28T15:17:00.000+08:00

聰明的女人選擇會願意愛自己一輩子的男人；
聰明的男人選擇會願意照顧、呵護一輩子的女人；
傻男女則是除了會做出聰明男女相反的選擇外還會犯一個相同的錯誤！
「愛不對人！！！」

求婚大作戰-最終回：打開奇跡之門

2007-06-27T22:57:00.000+08:00

這是健與禮小時候的一段話。
健：「我會負責的，會一輩子照顧禮的」
禮：「拜託你了！」

妖精對著健說：「
你要繼續尋找奇跡之門啊！
無論如何都想改變命運，
唯有這樣持續祈禱方能開啟奇跡之門，
打開那道門的鑰匙就在你心中，
只是你沒注意到罷了。
」

回顧過往健與禮的對話。
健：「人生裡有沒有想要重新來過的時候，有沒有後悔的事情」
禮：「我啊，高中的時候一直在想，我們為什麼是青梅竹馬呢？如果不是青梅竹馬的話，可能會更加坦率一些吧！可能就不用這麼痛苦地一直暗戀了。想了很多，但我明白了是不應該否定這一點。想著雖然那個時候覺得很痛苦，很失敗，但如果沒有這一點的話，就沒有今天的我在這裡笑著。這麼想就覺得沒有什麼值得後悔的事情。我覺得能和健認識真的太好了！是不是覺得現在我很少見的坦率一回了呢！雖然知道以後還有各種各樣的事，只有健的存在是永遠不變的。雖然到現在在健的面前一直不能坦率，但是我覺得因為有健，才會有現在的我。謝謝你！真的很感謝你！」

健心想：「禮沒有後悔過去，而是活在當下，接受了過去的一切，毫不動搖地活在當下。對於想要重新來過的我來說，禮的純潔，十分耀眼，刺痛了心裡。為什麼小時候，那麼容易就能辦到的事情，越長大就變得越困難呢？跟失敗比起來，根本沒有做的後悔會痛苦好幾倍。現在目的地不知道是否有奇跡的大門，但覺得應該試著想相信我自己。」

回到現實妖精為健準備了最佳的舞台。
妖精：「
重要的，不是感嘆過去的現在，而是改變現在，面向未來的意志。
我為你準備了，總算能表達自己回到過去，經歷拼命磨練的痛苦洗練的答案合適的地方。
祈願吧！你祈願我就替你實現。
尋求吧！你尋求我就替你發掘。
叩門吧！你叩門我就替你打開。
好了，挺起胸膛，走下去！
」

婚禮上健的致辭。
健三：「
我和禮從小學開始就是同學，
昨天在小學畢業紀念冊上看到，禮在上面寫到將來夢想成為一個可愛的新娘，
現在看來對他可不可愛還有很多疑問，這暫且不論，總之她能實現自己從小的夢想
…………………………
雖然對不起多田先生，我想過如果禮放棄結婚就好了。
我也想過搶走禮，14年中，歡樂的時候也好、痛苦的時候也好、
難過的時候也好，都一起度過的禮。
真心覺得能讓他幸福的只有我，一點兒不順心就馬上鬧彆扭的禮、
因為我逃避掃除和工作而常常生氣的禮，倔強，一點兒也不坦率的禮。
最了解她的是我，看起來堅強，其實很細膩的禮。
自己的事總是放在第二位，比誰都重視朋友的禮。
一直在身邊的禮，最需要他的是我。
但是，最終只是在心裡想著，在禮面前從來沒有坦白過。
一直在身邊，想著隨時都可以說的話。
最終一次都沒有說出口。
只有那麼一句話，但是一次都沒有說出口。
我…我喜歡過禮。
說真的，現在也喜歡著禮！
但是，禮在今天和多田先生結婚了。
雖然很不甘心，但是他甘要結婚了。
禮的存在，在我的心裡十分重要。
這些話，為了說出口花了好長的時間。
禮，恭禧你結婚，請你過得幸福。
沒有幸福的話，不幸福的話，我可真的不原諒你哦！
」

禮內心的掙扎。
禮：「
我的身旁，總是有岩瀨健。
我的回憶，也總有著健的身影。
健的溫柔，總像無意間在哪兒繞了點路。
要稍稍慢一拍才會傳達給我…
如今的我才能察覺到那份笨拙的溫柔。
當時的自己，總是無法那麼坦率。
明明很開心卻說不出口。
好鄙視這樣的自己。
害怕被傷害，而沒能鼓起勇氣到最後的人…是我
沒能一直相信健的溫柔就中途放棄的人…是我
決定了不再回頭，就單方面閉上眼的人…也是我
健他總是一直在認真的投球，沒能好好接住的人…是我。
我們的人生，總是不斷錯過。
害怕再這樣繼續錯過
不要再搖擺，不要再猶豫
那時明明就決定了
要是…要是那時候
能對自己誠實一點的話
是不是就能把一直沒能說出口的話
"我喜歡你"這樣一句話…說出口了呢？
」

妖精給予禮的最後協助，打開奇跡之門。
妖精：「
J.S韋斯曾經說過
男人無法放棄初戀
女人則無法放棄最後的愛
曾有個男人展開一段重寫過去悔恨的旅程
他拼命努力想改變過去
無奈奇跡之門終究沒有打開
在旅程的最後他發現了
再怎麼改變過去，自己還是不會改變
於是他想到了，比起感嘆過去的現在
改變現在，面向未來的意志才是最重要的。
你不覺得，現在開始還來得及嗎？
」

Liferay Portal單一使用者登入

2007-06-27T16:52:00.000+08:00

在啟動Liferay後，如果同一個使用者連續開啟Browser進行登入後結果會是如何，真正實作後會發現，我們同樣使用test@liferay.com這個帳號進行二次登入後，在Session中會有二個Session的記錄，並且這二個同樣帳號的使用者可進行完全符合該帳號權限的操作，那我們要如何限制使用者帳號只能進行單一的登入呢？

圖：預設狀況下，同一使用者進行二次登入的結果。

如果手邊有Liferay的Source Code的話，可以找一下，在原始碼[portal-ejbclassesportal.properties]中的設定。

portal.properties

# Set the following to true if users are allowed to have simultaneous logins

# from different sessions.

auth.simultaneous.logins=true

這個設定主要用途在於設定是否允許相同帳號的使用者同時間進行登入，換句話說就是允許同一使用者進行多次的登入，因為預設為true，所以才會有上述的狀況出現。

若不希望同一時使用者進行多次登入的話可將該設定改為false即可，但在原始碼中修改並不明智，畢竟你修改了預設的設定，比較聰明的方法為，在已經佈署的Liferay Portal上進行調整，你可以開啟[%LiferayPortal%webappsROOTWEB-INFclassesportal-ext.properties]這個延伸設定檔，在當中進行設定將會覆蓋掉預設的設定。將其修改為auth.simultaneous.logins=false後重新啟動liferay，再次進行二次相同帳號使用者登入。

實作後會覺得有些吊詭的情況，還是允許二次相同帳號的登入如下圖：

圖：還是一樣的狀況

但當我們將第一次登入帳號的Browser進行任何操作時將會發現出現結果如下：

圖：警告有相同的帳號用不同的Session登入。

這個意思就代表了第一次登入的使用者因為在之後已有其他相同的使用者進行了登入，因此被踢出了Portal系統。這時我們再檢查一次第二次登入的Browser的Session資訊：

圖：得到滿意的結果，因先前登入的User已被踢出，所以只有一個使用者登入。

好，最後我們來個結論，這個設定只會限制在Liferay Portal中無論使用PC的IP為何，使用者只能進行單一的登入，這麼看來似乎很像達成了SSO( Single Sign On )單一使用者簽入的任務，但其實不然，SSO是基於多個系統的單一簽入，因此多個系統一定會共用一個驗證中心，有興趣的話可以找一下Liferay Portal與CAS進行SSO的資料。在本例中，因為Liferay Portal只是單一一個系統，因此談不上SSO。

專家、高手與好顧問

2007-06-25T14:43:00.000+08:00

專家只是訓練有素的狗、高手只是有好習慣的工程師…

而好顧問則是什麼事都沒做，卻用了影響力讓公司朝正確方向前進。

(2006.04月號－147期)_實踐專案管理，使用Maven

2007-06-25T13:53:00.000+08:00

在小型專案與一般於企業中建置的J2EE專案中，經常因導入的AP Server平台的不同而統一使用特定的IDE開發環境，例如：IBM的WebSphere使用WSAD、Oracle的OC4J使用JDeveloper、WebLogic使用Workshop等。

當進行大型專案開發，並分割出多數的系統模組都委外進行開發時，每一間委外廠商可能都使用不同的開發工具與IDE進行開發，因此如何管理、建置、佈署專案就是一門學問了。

而以往J2EE專案依IDE開發環境不同有不同的建置與佈署邏輯，而這些建置與佈署方式彼此並不相容，例如在WSAD建置的設定，無法移植至JDeveloper與Workshop使用，反之亦然，這對日後的維護上也將更形困難，我們沒辦法保證，當時開發時的IDE與目前維護時使用的IDE開發工具是相同的。

若欲將各模組委外進行開發，管理跨J2EE平台建置的大型專案，Ant是個很好的選擇，Ant可以撰寫腳本進行所有動作，要求委外廠商進行模組開發使用Ant也不是問題，因為目前業界大多數也是如此進行開發的。

但問題在於其Ant建構人員必須非常熟悉專案建置邏輯，並且善用一些開放原始碼元件協同進行開發、測試與佈署，若只是單純使用Ant基本腳本功能的話，則頂多也只是將原先手動進行複製、刪除、編譯、封裝JAR、WAR、EAR的動作轉為自動化而已，實質上並沒有太大的意義，還不如撰寫批次檔進行自動化來得簡單方便。

遺憾的是，於Ant中協同其他元件進行Ant功能的擴充並沒有想像中的簡單，參考設定 1中可以發現，於Ant中欲使用Cactus進行容器測試，必須進行以下步驟。

步驟1：首先必須於init中設定cactus的擴充標籤runservertests。

步驟2：testwar中進行原始碼的編譯與封裝。

步驟3：prepare.test.tomcat.40中複製出tomcat環境並進行佈署。

步驟4：test.tomcat.40中使用runservertests擴充標籤執行start.tomcat.40啟動tomcat、執行test進行容器測試、最後執行stop.tomcat.40關閉tomcat。

基本上，建構人員並不想建置這麼複雜的設定、不想引入這些與專案原始碼無關並且只供測試用的jar檔、不想了解tomcat伺服容器的結構，更不用說怎麼去啟動與關閉tomcat了。但若專案欲於Ant上使用Cactus，這一切似乎是無可避免的，一旦加入的擴充元件愈多，Ant腳本將愈來愈複雜，目前Ant中只加入了tomcat的設定，試想當專案需要於WebLogic、Resin、JBoss進行測試時，撰寫的Ant的腳本檔將會有多複雜與難以維護。

另外，在設定 1中我們也發現，多個專案中運行Cactus時的設定都是大同小異的，因此可以將其抽出作為template，並以ENTITY方式進行引入，於多個專案中使用。這是個很好的解決方案，解決了設定上的複雜性，卻還是免不了必須在專案中放置相依的jar檔，當建構範圍愈來愈大相依jar檔的管理也更加麻煩。更何況Ant中只包含建置邏輯的腳本，雖然目前在各IDE開發環境中幾乎都已支援Ant，但Ant並無法反向建置出各IDE開發環境的設定。

當使用版本控制程式進行管理時，相依jar檔愈多將使納入版本管理的程式愈顯龐大，但實際上該納入控管的只有原始碼而已，所有jar檔應該抽出並且共用才對。而若將IDE開發環境的設定納入控管則會造成災難，開發人員都會希望自己的開發環境是方便且友善的，為了如此的目的多多少少都會修改其相關設定，當每一位開發人員都有權利對IDE設定進行commit時，我們將發現開發環境的設定將會是一團亂，甚至於造成專案無法正常開啟。

總結上面所述，跨J2EE平台的專案管理工具最好能符合以下條件。

由建置設定檔反向產生個別IDE開發環境設定，並且由建置人員將IDE設定檔排除在版本控制之外。
將所有相依的jar檔統一放置於貯藏庫(repository)中，於建置專案的同時進行連結與Classpath的引用。
將所有經常使用的建置邏輯抽出成為template，並強迫使用統一的建置邏輯，才不會因為不同的建置人員而寫出不同的建置腳本檔，而使日後維護更加艱難。
將所有第三方協同專案開發的套件進行封裝，成為一個外掛模組。例如將Cactus封裝成為Plug-in，而之後只需簡易的呼叫Plug-in進行協同作業而無須理會原先該套件使用上有多複雜。

筆者於139期的RunPC中直接使用Maven進行了簡易專案開發的示範，從本期開始將與讀者一同分享，如何使用Maven完成上述的要求，並且更進一步的超越使其成為專案管理與建置工具的最佳實踐。

設定 1 於Ant中使用Cactus設定

[...設定cactus擴充標籤...]

</taskdef>

</target>

<target name="test.tomcat.40"

depends="prepare.test.tomcat.40">

<runservertests

testURL="[cactus測試網址]"

startTarget="start.tomcat.40"

stopTarget="stop.tomcat.40"

testTarget="test"/>

</target>

<target name="prepare.test.tomcat.40"

depends="check.test.tomcat.40,testwar">

[...設定Tomcat環境並將測試War檔進行佈署...]

<copy file="[...]/test.war"

tofile="[...]/webapps/test.war"/>

</target>

[...進行封裝War檔...]

</war>

</target>

[...設定Classpath並啟動tomcat...]

</java>

</target>

[...設定Classpath並關閉tomcat...]

</java>

</target>

[...設定cactus所需要的Classpath...]

</classpath>

</junit>

</target>

Maven的起源

Ant曾經是筆者認為絕佳的建置工具，畢竟Ant為Another Neat Tool(另一個很棒的工具)的縮寫。經過多次專案的歷練後發現，要建置與維護多個Ant腳本的專案將非常的不易。而Maven的起源最初是由於進行Jakarta Turbine專案，原先專案中每一個check in到CVS的不同的JAR檔都擁有他們自己的build files，在進行維護上相當的困難，因此能夠進行很簡單的建置，並且定義出一個建置多個project的標準、一個對project構成清晰的描述、一個簡單的方式發佈project的資訊與一個能夠通過幾個不同的project去分享不同的JAR檔的方式就成為Maven這個專案的目標。

現在的Maven將可以協助開發人員更容易的進行日常工作的建立與更輕易的理解所有Java-based開發的專案。

因此可以在最短時間內使開發人員導入目前專案的開發。並且提供以下幾個特點。

使專案建置的過程更加容易
提供一個通用的專案建置系統
提供建立高品質的專案開發資訊
提供最佳化實踐的專案開發指南
允許以通透的方式進行新功能的整合

理念上Maven是一個管理與整合專案開發的建置工具，在使用上基於XML概念的Project Object Model (POM-專案元件模型)的設計，並且實際上Maven的架構與核心是非常微小的，幾乎所有的功能都是由Plugins所提供，因此，在Maven中對於Plug-in的應用非常重要。

Maven1.x環境設定

Maven相容於大多數的OS平台，讀者可參考設定 2與設定 3進行Maven環境的指定並執行maven確認是否正確執行。

首次執行時，Maven預設將[MAVEN_HOME]/plugins下所有jar檔進行解壓縮放置於${user.home}/.maven/cache路徑下，在Windows中是置於C:Documents and Settings[登入帳號] .mavencache，於Linux則是置於/home/[登入帳號] /.maven/cache下，這些所謂的plugins大多是基於Jelly語言所定義的建置腳本，也將是日後我們最常使用的套件。

Maven對於相依jar檔的管理則提供了Remote & Local Repository進行集中的管理，預設Remote Repository指向http://www.ibiblio.org/maven網站而Local Repository置於${user.home}/.maven/ repository下，Maven運行過程中相依的檔案會經由Remote Repository下載至Local Repository存放。

將plugins與local repository置於${user.home}/.maven/cache與${user.home}/.maven/ repository，原意在跨平台環境下都能指向開發人員登入後User Home的資料放置路徑，但通常在實際開發中我們會希望將其路徑指向特定位置。

設定 2 Maven於Windows平台設定

set MAVEN_HOME=[maven放置路徑]maven
set PATH=%MAVEN_HOME%bin;%PATH%

設定 3 Maven於Linux平台設定

export MAVEN_HOME= [maven放置路徑] /maven
export PATH=${PATH}:${MAVEN_HOME}/bin

Maven參數設定與優先權

在此我們可以參考圖 1進行參數的修改，該圖說明了Maven中參數優先權的順序，在Ant中當使用property標籤進行設定之後，將無法再次修改其參數值，而Maven與Ant的差異在於Maven依照設定檔放置的位置不同擁有其不同的優先權。

讀者可自行解壓縮[MAVEN_HOME]/lib/maven.jar，當中可以發現名為defaults.properties，該檔為所有預設參數放置的位置。另外在我們建置的專案中皆可包含二個設定檔，分別為project.properties與build.properties，並且build.properties優先權高於project.properties，也就是說當這二個檔案中使用相同參數時build.properties所設定的值會替代project.properties的值。但這二個檔案的用意究竟為何？一般初次接觸Maven的人都會搞混，觀念上來說project.properties所存的參數多為專案所需使用的參數，build.properties所設定的參數則為建置專案時所需的參數。

以另外一個觀點來說，假設於目前專案開發階段，我們將程式碼納入版本控管，並在一部測試伺服主機上進行自動化的每日構建與測試，則我們可以將這部測試機或正式機上所需的建置參數指定給project.properties並將該檔納入版本控管當中。因此在進行Daily Build時可以從project.properties取得參數。

而開發人員於自己的開發環境中進行check out原始碼後，一樣可以從版本控制系統中取得project.properties，但該檔的設定並不一定與目前開發人員的環境相同，因此建置上可能會發生問題，為此開發人員可自行建立build.properties並將設定上的不同處進行覆寫，來完成專案建置與測試。而build.properties我們通常不納入版本控管當中。另外Maven中協同多專案進行開發是非常容易的，所以目前進行開發的專案，有可能是父專案中的子專案，也因此繼承了父專案的相關屬性，在父專案下亦可包含project.properties與build.properties二個設定檔。

在User home的路徑下，也就是C:Documents and Settings[登入帳號]，是屬於優先權次高的設定檔，通常在此進行對預設參數的覆寫，以取代原始的預設值，參考設定 4在這裏重新指定了maven.home.local與maven.repo.remote，透過maven.home.local參數的覆寫，相對的也指定了.maven/cache與.maven/ repository的路徑，這一點可以從maven.jar中的defaults.properties的設定maven.repo.local=${maven.home.local}/repository與maven.plugin.unpacked.dir = ${maven.home.local}/cache找到解答。

若為了加速下載速度或是企業內部網路受限的環境下而必須設定代理伺服器可使用設定 4中maven.proxy相關參數進行設定，該設定中亦支援NTLM授權。但在網路管制較嚴格的企業中，代理伺服器的設定可能還是無法使Maven順利進行檔案下載作業，則這時必須求助於網管人員調整其網路權限。

使用Command line方式進行設定的參數將覆蓋之前所有的設定，參考設定 6中我們運行了plugin:download並覆寫參數maven.repo.remote以及其他參數。使用方式同java參數設定-Dproperty=value，擁有最高的優先權。

設定 4 User home下的build.properties

#設定cache與repository放置路徑

maven.home.local=${maven.home}/.maven

#設定remote repository網址

maven.repo.remote=file:E:/maven/maven.remote.repository,

http://www.ibiblio.org/maven,

http://maven-plugins.sourceforge.net

#Maven使用代理伺服器

maven.proxy.host=[代理伺服器網址]

maven.proxy.port=[代理伺服器Port]

maven.proxy.username=[帳號]

maven.proxy.password=[密碼]

maven.proxy.ntlm.username=[帳號]

maven.proxy.ntlm.password=[密碼]

圖 1 參數優先權設定順序

資料結構、groupId與artifactId

Maven提供了許多的Plug-in，讓專案建構變得非常簡單。但Maven對於建置專案也有限制，其限制就是每個專案﹙在Maven中一個專案是指帶有project.xml的一個資料夾﹚只能生成一個成品（artifact）。但這個限制對於複雜的專案架構上並沒有問題，因為Maven支援多專案的建置。一個Maven專案可以由子專案，每個子專案可以建置產生自己的成品，最頂層的專案可以將子專案的成品打包進行封裝生成JAR、WAR、EAR。並且Maven在專案之間還提供了繼承（inheritance）。

Maven使用了groupId與artifactId的觀念，參考資料結構 1，當進行小型專案的建置時，我們只需要類似artifact-id-implement或artifact-id-war簡易的建出JAR或WAR即可，這時groupId與artifactId通常是相同的。但若進行大型專案的建置，將可能將企業邏輯進行抽像化，產生介面、實作與其共用元件，而多個介面、實作、共用元件配合WAR與EAR的建置就可對大型專案進行封裝與佈署，如此的分層架構規劃下，許多Maven建置的artifact都將可以輕易的在各專案的建置下重覆使用，而這時的groupId與artifactId就必須有不同的名稱。例如Spring這個Framework，其groupId為org.springframework，而分別依功能區分了spring-aop、spring-beans、spring-context、spring-dao…等的artifactId。

註：關於project.xml中groupId與artifactId的設定請參考139期的Run PC。

資料結構 1 Maven資料夾結構

group-id

|-- artifact-id-interface

| |-- src/

| | |-- main/

| | | |-- java/

| | | | `-- ...

| | | `-- resources/

| | | `-- ...

| | `-- test/

| | |-- java/

| | | `-- ...

| | `-- resources/

| | `-- ...

| |-- project.xml

| |-- maven.xml

| |-- project.properties

| `-- build.properties

|-- artifact-id-implement

| `-- ...結構同上...

|-- artifact-id-war

| |-- src/

| | |-- java/

| | |-- resources/

| | `-- webapp/

| |-- test/

| | |-- java/

| | `-- resources/

| |-- project.xml

| |-- maven.xml

| |-- project.properties

| `-- build.properties

|-- project.xml

|-- maven.xml

|-- project.properties

`-- build.properties

建置Maven的組件與其核心架構

Maven的基本概念就是Project，每一個目錄包含有project.xml的目錄都是一個Project，而另一個概念就是Repository。當運行maven命令時，將會從Remote repository中複製於project.xml中dependency標籤所相依的jar檔到Local repository，然後建構專案，封裝成品。參考設定 5與圖 2，Maven依groupId建立一個子目錄，在groupId資料夾中依所需的artifactId進行下載指定type的檔案，這裏所指的type有jar、ejb、plugin…等設定，若未指定則預設為jar。在設定 5的範例中將會建立groupId為org.springframework的資料夾並於預設type為jar的條件下建立jars資料夾並下載指定規則為<artifactid>-<version>.<type>的spring-aop-1.2.6.jar、spring-beans-1.2.6.jar、spring-context-1.2.6.jar三個檔案於該資料夾內。

Repository的角色是相當明顯的，每個專案不再需要各自包含自己所依賴的第三方套件，Repository將會協助開發人員在多個專案間共用所有套件。而另一方面每個專案也可以自己建置成品，依Maven的觀念可使用install將套件安裝到Local repository，使用deploy將套件佈署到Remote repository。使用這種方式可以幫助開發者用一種標準的方式在專案間共用自製的套件。並且相互依賴的進行專案間持續整合（continuous integration）。若透過Cruise Control工具。專案可以持續的建置，最新釋出的成品可以重覆佈署到Repository中。在建置主機上運行持續性整合，將會定時的持續建構、發佈成品到應用伺服器中、進行自動測試並檢驗建置狀態。參考圖 3顯示了在Maven建置過程中project.xml、Repository、goal、plug-in各自的角色。

設定 5 於project.xml設定dependency

...

<groupId>org.springframework</groupId>

<artifactId>spring-aop</artifactId>

</dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-beans</artifactId>

</dependency>

<groupId>org.springframework</groupId>

<artifactId>spring-context</artifactId>

</dependency>

...

</dependencies>

圖 2 Repository資料夾結構

圖 3 建置Maven相關組件

Maven Plug-in

在Maven中幾乎所有功能都是由Plug-in所提供的，在Plug-in中包含了多個goal，而針對每個goal可以因應多個property的設定呈現不同的實作結果。例如Maven Jar Plug-in中原先在執行maven jar:jar這個goal之後，將進行原始碼編譯、測試並依artifactid-version.jar規則封裝成jar檔，而當我們在進行參數設定並加入maven.jar.final.name=xxxx.jar後重新執行，則最後封裝結果的檔案將會是xxxx.jar。

究竟目前在本機上有多少的Plug-in可用，在此我們可以執行maven -g列出所有的Plug-in，亦可以使用maven -g > goal.txt重導至檔案中慢慢查看，若已經知道欲使用的Plug-in卻不知該Plug-in提供多少goal，可使用maven -P [plugin name]則可列出指定的Plug-in中所有的goal，maven -g 與maven -P 列出格式參考資料結構 2。

Maven -g與-P參數可以清楚的知道有多少的goal可使用，但Plug-in中有多少property就沒有參數可以協助列出以供查看了，關於這個部分可以連至Maven官方網站http://maven.apache.org/maven-1.x/reference/plugins參考詳細的Plug-in說明文件。

Maven在預先安裝中就已經包含了大多數的Plug-in了，但若欲使用的Plug-in有bug或欲使用的功能於本機上的Plug-in尚未提供，則可至Maven官方網站中任選以下方式進行下載並安裝，。

方式1：手動下載指定版本Plug-in的jar，置於[MAVEN_HOME]/plugins下即可。
方式2：參考設定 6執行plugin:download並指定所需的Plug-in進行手動下載與安裝。
方式3：參考設定 7執行maven任一goal的同時進行Plug-in進行自動下載與安裝。

註：Maven中的goal與Ant腳本中的target是意義相同的，所指的都是預先定義好的任務，而Maven的goal是由Jelly（基於XML的標記語言）編寫的一系列命令腳本，而使用goal的語法為maven [plugin name]:[goal name]。

資料結構 2 maven -g 與maven -P 輸出格式

__ __

| / |__ _Apache__ ___

| |/| / _` V / -_) ' ~ intelligent projects ~

|_| |___,_|_/___|_||_| v. 1.0.2

Available [Plugins] / Goals

===========================

[plugin name1] 針對plugin name1的描述

goal name1 ..... goal name1使用描述

goal name2 ..... goal name2使用描述

goal name3 ..... goal name3使用描述

...

[plugin name2] 針對plugin name2的描述

...

設定 6 Maven手動下載Plug-in

maven plugin:download

-Dmaven.repo.remote=http://www.ibiblio.org/maven, http://cvs.apache.org/repository/

-DgroupId=maven

-DartifactId=maven-jar-plugin

-Dversion=1.7

設定 7 Maven於POM中設定自動下載Plug-in

...

<groupId> maven</groupId>

<artifactId> maven-jar-plugin </artifactId>

<type>plugin</type>

</dependency>

...

</dependencies>

Maven Goal

除了之前提過的project.xml、Repository與Plug-in之外，在圖 3中我們可以看到maven.xml檔的設置，這個檔案主要用途在於延伸、擴展與客製化Goal，並且在這個檔案中我們會使用到preGoal、goal、postGoal三個標籤進行Goal的定義。

參考設定 8中project標籤的default屬性設定為buildWeb，在Maven中的goal和Ant中的target是相同的概念，而且Maven中的default屬性的設定亦是相同於Ant。這個設定意味著在目前專案的目錄下，直接執行maven指令，這時將會執行的default的goal為buildWeb，在這個設定中buildWeb直接使用attainGoal標籤去執行另外一個goal為war Plug-in中的war這個goal。

從這個例子中我們可知，我們可以在goal標籤中撰寫所需的執行的Jelly腳本，當然這個腳本目前也相容於Ant的寫法，並且在goal中還可以使用attainGoal去執行其他Plug-in的goal。例如war:war這個goal依順序也會去執行java:compile、test:test、war:webapp…這幾個goal。

preGoal標籤則代表了在指定的goal執行之前所要執行的建構規則，如之前所提war:war運行過程中會去執行java:compile，而本例中在編譯之前將先行呼叫xdoclet:webdoclet這個goal協助在建置過程中產生web相關的設定檔。因此使用preGoal進行功能的擴展就無須直接修改java:compile這個goal。

同樣的postGoal的意義在於將在goal執行之後所運行的建構規則，在本例中當war:war完成後將產生一個war檔，透過postGoal功能的延伸的撰寫我們就可以進行簡易的tomcat的佈署動作了。

在Maven中無論是goal、preGoal、postGoal都可以嵌入任何Ant的task,。雖然給了Maven極大的靈活性，但是也很容易造成誤用，反而將之前使用Ant進行的設定、建置、佈署動作方式原封不動的搬到Maven來了，也就是說，只是在Maven的結構下依然故我的撰寫Ant的腳本，而造成在Maven下卻完全用不到Plug-in的好處。

建議在一般情況下，當找不到任何適當的的Plug-in時再自行撰寫，畢竟Maven最大的好處在於有無數的Plug-in可以使用，並且每一個Plug-in都是開放原始碼的心血結晶。

設定 8 maven.xml

<?xml version="1.0" encoding="Big5"?>

...在指定的goal之前執行建構規則...

</preGoal>

...建立一個新的或覆寫一個goal...

</goal>

<copy file="${maven.build.dir}/${pom.artifactId}.war"

todir="${tomcat.home.webapps}"/>

...在指定的goal之後執行建構規則...

</postGoal>

</project>

Maven1.x與Maven2.x的差異

目前上過Maven官方網站的讀者應該已經注意到，Maven2已經Release了，雖然Maven2與Maven1在概念上是非常相近的，但Maven2在架構上是對於Maven1完全的重寫，也因此將完全不相容。Maven1 Plug-in的部分也無法直接在Maven2上使用，而且因為效能考量下原先在Maven1建立Plug-in受到重用的Jelly語言，將不會在Maven2中出現，取而代之的將是回歸使用Java進行Plug-in的開發。

讀者看到這裏是否覺得，即然如此這時專案的開發應該全數移轉到Maven2上才是，也該放棄Maven1了。這也是當筆者看到Maven2的感想，但是實際上運作幾個Project後發現，雖然Maven2提供了不少相對於Maven1增加的新功能與特色，而且目前版本也尚稱穩定，但它最大的問題在於可用的Plug-in還不多，而少數的Plug-in目前還有Bug。

這是理所當然的，想當初Maven1也是經過二、三年的時間才延伸出這些為數可觀又好用的Plug-in，若要Maven2的Plug-in能夠成長到一個地步則還需要一段時間，但讀者無需擔心，目前Maven1建置的資料夾結構移到Maven2還是可以共用的，若日後需移轉到Maven2時，只需加上pom.xml並依Maven2規範設定就可以完成相容於Maven1與Maven2的專案了。

相關資源

1. http://maven.apache.org/ Maven官方網站

2. http://www.theserverside.com/articles/article.tss?l=MavenMagic

Srikanth Shenoy 於 TheServerSide.com發表的MavenMagic文章

3. Maven: A Developer's Notebook

By Vincent Massol, Timothy M. O'Brien