JWorld@TW the best professional Java site in Taiwan
      註冊 | 登入 | 全文檢索 | 排行榜  

» JWorld@TW » Java Tools  

按列印兼容模式列印這個話題 列印話題    把這個話題寄給朋友 寄給朋友   
reply to topicthreaded modego to previous topicgo to next topic
己加入精華區
by koji at 2008-08-16 23:29
本主題所含的標籤
作者 Maven 入門(1) - Maven 簡介 [精華]
qrtt1





發文: 1747
積分: 31
於 2008-08-16 20:18 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
什麼是 Maven ?

Maven 這個字的語源來自於 Yiddish Language,這是猶太人混合使用德語、希伯來語而成的方言。字面上的意義為「知識的累積者」。而 Maven 這套工具的起源則來自於 Jakarta Turbine project 的開發。當時參與專案的人觀察到許多的專案都寫著自己的 Ant Build 檔案,並使用相似的 JARs (大都將 JARs 放進了 CVS 之內)。除了原始碼之外,將二進位資料放進 CVS 做版本控制是不具意義的,不但無法做前後版本的差異比較,反而浪費許多檔案傳輸的時間。這時開者專案的人反思「是不是能有一個標準化的方式建立專案呢?透過簡單地定義需要使用那些 JARs、將要輸出什麼樣的成品、製作那些報告」。最大的目標希望能讓不同的專案在獨立於原始碼之外,有一套管理 JARs 的方式,讓它們能分享共同的部分,再補足差異的檔案。Maven 就是這樣誕生的!

您可能會有疑問:Maven 是用來取代 Ant 的嗎?我想並非如此,它們只是運用不同的軟體建構思維。Ant 的誕生來自於 Java 專案在建立上的不便與不統一。Ant 希望提供像 Make 般具有彈性卻又相當統一的做法。Maven 則將焦點放在一致的專案架構,統一的專案建構流程,並且對於 JARs 的管理下足不少功夫。所以 Maven 與 Ant 處理的問題是不同的,並且在 Maven 提出對於 JARs 檔不易管理的省思,並提出解決方案之後。Ant 社群發展出 Ivy 套件,它能像 Maven 般地管理 JARs。

什麼是 POM ?

在先前提過 Maven 希望能將專案的建立標準化,也許是有共通的 Metadata 描述方式,共通的目錄配置方式,共通的建構流程。要達到這樣的目標有一項基礎建設是相當重要的:POM (Project Object Model)。簡單地說,將專案當作一個物件模型來處理,就像您自行建立了一個 Project 物件,並使用 getXXXX() 方法取得資訊那樣的簡單。在實作上雖然不是三言二語能說明白,但 Maven 就是這樣來處理專案,而 POM 的實體是名為 pom.xml 的檔案。它選用 XML 為作資訊保存的方式,這能方便程式端的取用。

POM 裡可以包含許多資訊:專案名稱(artifactId)、專案版本號、專案相依的 JARs。以上是您尚未接觸 Maven 前可以猜到的,除了這些您可以安插許多 Maven Plugin,這些我們會在稍後解說。您必需先知道的是一個 pom.xml 最基本必要的內容(省略 xmlns 等資訊):

1
2
3
4
5
6
<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.mycompany.app</groupId>
  <artifactId>my-app</artifactId>
  <version>1</version>
</project>


每個 pom.xml 是以 project 為根節點,在這個範例您看到它填上了:modelVersion、groupId、artifactId、version 這些是您寫一個基本的 pom.xml 必填的資訊。POM 經歷多個版本的演進,您可以選用您需要的版本,但您需要名確地指出要使用什麼版本,以便 Maven 做 Validation 的動作。而 groupId 我們會填上專案 package 起始的位置,artifactId 則是專案名稱;最後,您需要有版本號。真的只要填上這些就足夠了嗎?是的。因為其他未曾的將採用預設值,預設值會放在另一個 POM 裡,我們稱為 Super POM 就好像每個 Java Class 一定會繼承 java.lang.Object 一樣。

Super POM 裡含有一些必要的 Maven Plugin 設定,與相關的 JARs Repository URL。對您來說,最重要的是檔案放置的位置:

原始碼目錄(sourceDirectory):${專案起始位置}/src/main/java
測試原始碼目錄(scriptSourceDirectory):${專案起始位置}/src/test/java
資源檔案目錄(resource):${專案起始位置}/src/main/resources
測試資源檔案目錄(testResource):${專案起始位置}/src/test/resources

如果您沒有改變預設的配置,那麼就應該在相對的位置放上應用的檔案。

安裝 Maven

請由 http://maven.apache.org/download.html 下載 Maven。下載完畢後,請將它解壓縮,並且將 Maven 內的 bin 目錄設定至可執行路徑內。要確定您是否做了正確的配置,您可以使用查詢版本的指令:

1
mvn -version


1
2
3
4
C:\temp\my-app>mvn -version
Maven version: 2.0.9
Java version: 1.6.0_06
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"


reply to postreply to post
蝸牛角上爭何事?石火光中寄此身,隨富隨貧且歡樂,不開口笑是癡人。
my notes
作者 Re:Maven 入門(1) - Maven 簡介 [Re:qrtt1]
vincent_hwu





發文: 153
積分: 2
於 2010-12-14 01:09 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
對於使用Maven,我一直存在著不少疑問,但是我相信一個東西的發明一定為了解決某些東西,我相信Maven也是,我把我的疑問提出來,看看那位先進可以指導一下

1. Dependencise的管理,基本上這個論點我是非常支持的,因為我的經驗,雖然不至於心一橫就把所有找的到的jar files加進去,我都是慢慢加進去的,的確在這個過程中非常的壟長,但是這樣一來我也知道這個jar file要幹麻的,不過基本上Maven用來管理Dependencies的論點是成功的

2. 統一專案結構,移植方便
這個很明顯的,的確透過某種的統一性,一定可以達到移植性,跟閱讀性

3. IDE操作在開發過程繁雜.
的確,如果每一次都要做到完整到打包,中間經過clean,compile,jar 這個IDE可以幫我做到前兩步,而且是source code有異動才做,也只針對異動的source code做clean,compile,老實說節省了CPU很多時間,也減省了I\O
我是跳過測試這個步驟,的確是不好,但是不可能每一次都要跑完整個測試,的確這有點煩,但是如果我真的要跑也是可以透過IDE去執行全部的Test Cases,這感覺跟Maven也沒差多少,只有在
執行clean,compile,test,jar,deploy 可以一次做完全部,但是IDE也只在Test這個步驟需要多按一次的鈕,而且不一定每次都要去按,我相信很多人也都在使用Maven的時候,跳過或是根本就沒有使用Test,這樣兩者就更沒有差異了


reply to postreply to post
作者 Re:Maven 入門(1) - Maven 簡介 [Re:vincent_hwu]
DraculaCwg





發文: 235
積分: 4
於 2010-12-14 14:38 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
我不知道有沒有會錯意,因為上下文中沒有提到

3. IDE操作在開發過程繁雜.

這句話會不會是指IDE的設定,而不是指開發的complie -> testing -> run 的processing

Maven可以透過一個簡單的指令 ex: maven eclipse:eclise , maven idea:idea , maven netbeans:entbeansQuestion
這樣,其他的user不用設定一堆lib即可"立馬"在自已偏好的IDE上開發,也不用把自已ide的config檔往svn送
這個在一個團隊,每個人都習慣用不同ide時,更是有很大的幫助


DraculaCwg edited on 2010-12-14 19:05
reply to postreply to post
作者 Re:Maven 入門(1) - Maven 簡介 [Re:vincent_hwu]
qrtt1





發文: 1747
積分: 31
於 2010-12-14 18:11 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
vincent_hwu wrote:
對於使用Maven,我一直存在著不少疑問,但是我相信一個東西的發明一定為了解決某些東西,我相信Maven也是,我把我的疑問提出來,看看那位先進可以指導一下

1. Dependencise的管理,基本上這個論點我是非常支持的,因為我的經驗,雖然不至於心一橫就把所有找的到的jar files加進去,我都是慢慢加進去的,的確在這個過程中非常的壟長,但是這樣一來我也知道這個jar file要幹麻的,不過基本上Maven用來管理Dependencies的論點是成功的

2. 統一專案結構,移植方便
這個很明顯的,的確透過某種的統一性,一定可以達到移植性,跟閱讀性

3. IDE操作在開發過程繁雜.
的確,如果每一次都要做到完整到打包,中間經過clean,compile,jar 這個IDE可以幫我做到前兩步,而且是source code有異動才做,也只針對異動的source code做clean,compile,老實說節省了CPU很多時間,也減省了I\O
我是跳過測試這個步驟,的確是不好,但是不可能每一次都要跑完整個測試,的確這有點煩,但是如果我真的要跑也是可以透過IDE去執行全部的Test Cases,這感覺跟Maven也沒差多少,只有在
執行clean,compile,test,jar,deploy 可以一次做完全部,但是IDE也只在Test這個步驟需要多按一次的鈕,而且不一定每次都要去按,我相信很多人也都在使用Maven的時候,跳過或是根本就沒有使用Test,這樣兩者就更沒有差異了


雖然,您想要提出疑問,不過好像沒有疑問句在文章裡。
我試著就我想回饋的部分加以回應:

Maven 是 building tool 不是 IDE,就像我們不會拿 ant 來與 IDE 相比。
即使用了 m2eclipse 我們也幾乎不會在開發未完成時,使用到 maven 相關指令。

就我個人使用的習慣來說,
我用 m2eclipse 主要是為了 Maven Dependencies 的
CLASSPATH_CONTAINER 能自動引用 pom.xml 內定義的 library。

即使是一般的 java project 我也習慣會配合 ant build script 使用,
但這不表示我就得禁止,自己享受 eclipse 的 incremental builder。
用 ide 就是要來爽的,不然只是徒增困擾。

另外,關於文中提到的,略過 test 來加快速度。
這要看待開發者個人,如何在工作中採用 test 的策略。
基本上,無論有沒有用 maven,我都會執行 test。
有些情況適合 test-driven,
有些情況用它來做固著 refactoring 副作用發生的範圍。
以個人偏好來思考:要不要執行 test 的流程來討論,其實是得不出結論的。
就個人開發而言,依賴 ide 許多“懶人化“的 plugin 都會比執行 maven 來得舒適。

那 maven 這一套完整的“軟體“建構流程,是餅畫大了還是鄙人如我不懂得欣賞呢?
軟體開發的概念,早就該脫離透過個人以簡單的想法,來做出個勉強可用的東西的時代了。

http://en.wikipedia.org/wiki/Software_configuration_management
* http://en.wikipedia.org/wiki/Build_management
* http://en.wikipedia.org/wiki/Continuous_integration

在 Software configuration management 被正視前,
我們對於版本控制與建構軟體是分開來看待的,
但是持續性整合,將這些既有或新生的
[軟體建構工具]、[版本控制工具]、[軟體測試(主要為單元測試)]工具或概念形成一個體系。

http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson

透過持續性整合工具(ex. Hudson CI),
您可以不間斷地由版本控制系統,取出最新的 source code。
執行完整的建構流程(maven 在這裡發揮了良好的作用),
除了編譯與測試 maven 更參與了軟體組態的活動,因為它包含了相依性管理。
您可以直接、間接測試相依性套測的變更是否產生了負面影響。

這裡指的相依性管理,
非指單純地,在一個 public repository 引用已廣為流傳具有品質的 library
以 maven 建構的專案,在公司內部我們會有自己的 private repository
當您的專案成果告一段落,您除了 package 給自己用,還需要 deploy。
至少,您得先通過直接的 unit test,再上傳至 private repository。

這讓錯誤的發現的時機得以提早,發生的範圍能有效的定義出來。
沒有人能寫出沒有 bug 的程式,但我們能及早發現,及早治療。


qrtt1 edited on 2010-12-14 20:32
reply to postreply to post
蝸牛角上爭何事?石火光中寄此身,隨富隨貧且歡樂,不開口笑是癡人。
my notes
作者 Re:Maven 入門(1) - Maven 簡介 [Re:qrtt1]
vincent_hwu





發文: 153
積分: 2
於 2010-12-14 22:49 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
非常的抱歉,因為在我提出問題的同時,天秤的兩頭依然在角力....所以有點言不及義

因為在我花時間看了Maven之後,發覺的確在每次的建立程式碼,測試,部署[如果是Web的話]...這個Cycle是要越小越好,這是我七年的感受,但是在每次想辦法要縮小這個Cycle的時候,總是找不到一個好的方法,Maven是在我在找這個辦法過程中所看到的

基本上它解決了Dependecis 問題,因為的確Dependecis 是個很煩人的問題,重點是Dependecis 還是傳遞
A-->B-->C 然後最後只能慢慢挑進去,要不就等到錯誤在加進去...這些都是很多的風險....Maven解決了,它也解決了大型專案裡的Dependecis 問題,A Module --> B Module,透過私服的發佈的確有個良好的解決方法....

我只是把它跟IDE的functionality搞混了,不過在你分享經驗之後我有豁然開朗的感覺,至於那個CI跟測試的問題,這個沒有解...我請求跪求花人日在上面,但是這是永遠的痛.....我相信大家都有感想.....當什麼都犧牲的差不多的時候,測試就會整個犧牲,只剩下那感覺有章法又沒有章法的uat


reply to postreply to post
作者 Re:Maven 入門(1) - Maven 簡介 [Re:vincent_hwu]
qrtt1





發文: 1747
積分: 31
於 2010-12-15 08:32 user profilesend a private message to userreply to postreply to postsearch all posts byselect and copy to clipboard. 
ie only, sorry for netscape users:-)add this post to my favorite list
vincent_hwu wrote:
我只是把它跟IDE的functionality搞混了,不過在你分享經驗之後我有豁然開朗的感覺,至於那個CI跟測試的問題,這個沒有解...我請求跪求花人日在上面,但是這是永遠的痛.....我相信大家都有感想.....當什麼都犧牲的差不多的時候,測試就會整個犧牲,只剩下那感覺有章法又沒有章法的uat


CI 是可遇不可求的, 像我現在大部分時間在寫 C, 而且不太能拆開來 unit test。
但能派得上用場的"心法"都還繼續在做,
持續地 refactoring 改善自己的程式碼品質.

無論是測試或 refactoring 去求別人做實在有點卑微,
我們其實可以將它融入自己的工作循環之內,
讓別人默默看著, 我們所享受到的悠閒步調.

即使, 我現在在進行的專案(ex. android ndk), 不太可能做 unit test
但我依然建立了 unit test 的環境 (android test project).
透過 Android APP 上已建立的 api interface 來測試底層 native library 的行為.
這既省時, 又能快速 reproduce problem.
即便無法得到 unit test, 但用上他的邊際效應, 也是賺到縮小工作循環的優點.


reply to postreply to post
蝸牛角上爭何事?石火光中寄此身,隨富隨貧且歡樂,不開口笑是癡人。
my notes
» JWorld@TW »  Java Tools

reply to topicthreaded modego to previous topicgo to next topic
  已讀文章
  新的文章
  被刪除的文章
Jump to the top of page

JWorld@TW 本站商標資訊

Powered by Powerful JuteForum® Version Jute 1.5.8