<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                企業??AI智能體構建引擎,智能編排和調試,一鍵部署,支持知識庫和私有化部署方案 廣告
                找到了一篇博客,很多啊,是講Maven中的版本管理的,很好,分享一下, 原文作者:juvenshun 原文地址:[http://juvenshun.iteye.com/blog/376422](http://juvenshun.iteye.com/blog/376422) ------------------------------------------------------------------------------------- ### 什么是版本管理 ?????? 首先,這里說的版本管理(version management)不是指版本控制(version control),但是本文假設你擁有基本的版本控制的知識,了解subversion的基本用法。版本管理中說得版本是指構件(artifact)的版本,而非源碼的版本(如subversion中常見的rXXX,或者git中一次提交都有個sha1的commit號)。 ?????? 比如我有一個項目,其artifactId為myapp,隨著項目的進展,我們會生成這樣一些jar:myapp-1.0-SNAPSHOT.jar,myapp-1.0.jar,myapp-1.1-SNAPSHOT.jar, myapp-1.0.1.jar等等。你可能會說,這很簡單啊,我在POM中改個version,mvn clean install不就完了?但這只是表面,本文我將講述,snapshot和release版本的區別,如何自動化版本發布(如果你的項目有幾十個module,你就會覺得手工改POM來升級版本是很痛苦的事情),結合自動化發布的過程,這里還會介紹maven-release-plugin。此外,一些scm概念也會被涉及到,比如tag和branch。 ### 前提:版本控制 ?????? 不管怎樣,我們都需要建立一個項目并提交到SCM中,這里我以subversion為例。你得有一個配置好的subversion repository,這里我建立了一個空的svn倉庫,其地址 為:https://192.168.1.100:8443/svn/myapp/ 現在,該目錄下只有三個空的典型的子目錄:/trunk/, branches/, tags/。分別用來存放主干,分支,以及標簽。 接著將項目導入到svn倉庫中,到項目根目錄,運行如下命令: ~~~ svn import -m 'project initialization' https://192.168.1.100:8443/svn/myapp/trunk ~~~ (注意,這么做你會將目錄下所有文件導入到svn庫中,但是這其中某些目錄和文件是不應該被導入的,如/target目錄,以及eclipse相關的項目文件) 目前,我們將項目的版本設置為1.0-SNAPSHOT。 ### 為什么用SNAPSHOT? ?????? 我先說說如果沒有SNAPSHOT會是什么樣子。假設你的項目有2個模塊,A,B,其中A依賴B。這三個模塊分別由甲,乙兩個個人負責開發。在開發過程中,因為A是依賴于B 的,因此乙每次做一個改動都會影響到甲,于是,乙提交了一些更改后,需要讓甲看到。這個時候,怎么做呢?乙對甲說,“你簽出我的代碼,build一下就OK了”,甲有點不情 愿,但還是照做了,簽出代碼,svn clean install,然后,發現build出錯了,有個測試沒有pass。甲郁悶了,對乙說,“你的代碼根本不能用,我不想build,你build好了給我”, 乙看了看確實自己的代碼build不過,于是回去解決了,然后打了個jar包,扔給甲,甲對了對groupId,artifactId,放到了自己的.m2/repository/目錄下,OK,能用了。 于是乙每次更新都這樣做,打包,復制,然后甲粘貼,使用……漸漸的,大家發現這是個很笨的辦法,這是純手工勞動阿,程序員最BS的就是重復勞動。一天,甲對乙說,“你知道nexus么?你把你的jar發布到nexus上就可以了,我要用就自動去下載,這多棒!”乙說“哦?有這好東西,我去看看”于是乙發現了nexus這塊新大陸,并成功的發布了B到nexus上。(見,[Nexus入門指南,(圖文)](http://juvenshun.iteye.com/blog/349534))。 ?????? 但是,請注意,我們這里的一切都假設沒有SNAPSHOT,因此如果乙不更改版本,甲下載一次如B-1.0.jar之后,maven認為它已經有了正確的B的版本,就不會再重新下載。甲發現了這個問題,對乙說“你的更新我看不到,你更新了么?”乙說“不可能!我看看”,于是檢查一下甲下載的C-1.0.jar,發現那是幾天前的。乙一拍腦袋,說“這簡單,我更新一下我的版本就好了,我發布個B-1.1.jar上去,你更新下依賴版本”,甲照做了,似乎這么做是可行的。 ?????? 這里有一個問題,一次提交就更新一個版本,這明顯不是正確的管理辦法,此外,乙得不停的通知甲更新對B的依賴版本,累不累阿?1.0,或者說1.1,2.0,都代表了穩定,這樣隨隨便便的改版本,能穩定么? ?????? 所以Maven有SNAPSHOT版本的概念,它與release版本對應,后者是指1.0,1.1,2.0這樣穩定的發布版本。 現在乙可以將B的版本設置成1.0-SNAPSHOT,每次更改后,都mvn deploy到nexus中,每次deploy,maven都會將SNAPSHOT改成一個當前時間的timestamp,比如B-1.0- SNAPSHOT.jar到nexus中后,會成為這個樣子:B-1.0-20081017-020325-13.jar。Maven在處理A中對于B的SNAPSHOT依賴時,會根據這樣的timestamp下載最新的jar,默 認Maven每天更新一次,如果你想讓Maven強制更新,可以使用-U參數,如: ~~~ mvn clean install -U ~~~ 現在事情簡化成了這個樣子:乙做更改,然后mvn deploy,甲用最簡單的maven命令就能得到最新的B。 ### 從1.0-SNAPSHOT到1.0到1.1-SNAPSHOT SNAPSHOT是快照的意思,項目到一個階段后,就需要發布一個正式的版本(release版本)。一次正式的發布需要這樣一些工作: 1. 在trunk中,更新pom版本從1.0-SNAPSHOT到1.0 1. 對1.0打一個svn tag 1. 針對tag進行mvn deploy,發布正式版本 1. 更新trunk從1.0到1.1-SNAPSHOT 你可以手工一步步的做這些事情,無非就是一些svn操作,一些pom編輯,還有一些mvn操作。但是你應該明白,手工做這些事情,一來繁瑣,而來容易出錯。因此這里我介紹使用maven插件來自動化這一系列動作。 ### SCM 首先我們需要在POM中加入scm信息,這樣Maven才能夠替你完成svn操作,這里我的配置如下: ~~~ <scm> <connection>scm:svn:http://192.168.1.100:8443/svn/myapp/trunk/</connection> <developerConnection>scm:svn:https://192.168.1.100:8443/svn/myapp/trunk/</developerConnection> </scm> ~~~ 需要注意的是,很多windows使用的tortoiseSVN客戶端,而沒有svn命令行客戶端,這會導致Maven所有svn相關的工作失敗,因此,你首先確保svn --version能夠運行。 #### 分發倉庫 想要讓Maven幫我們自動發布,首先我們需要配置好分發倉庫。關于這一點,見[Maven最佳實踐:Maven倉庫](http://juvenshun.iteye.com/blog/359256)——分發構件至遠程倉庫。 #### maven-release-plugin 緊接著,我們需要配置maven-release-plugin,這個插件會幫助我們升級pom版本,提交,打tag,然后再升級版本,再提交,等等。基本配置如下: ~~~ <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-release-plugin</artifactId> <version>2.0-beta-7</version> <configuration> <tagBase>https://192.168.1.100:8443/svn/myapp/tags/</tagBase> </configuration> </plugin> ~~~ GAV我就不多解釋了,這里我們需要注意的是configuration元素下的tagBase元素,它代表了我們svn中的tag目錄,也就是說,maven-release-plugin幫我們打tag的時候,其基礎目錄是什么。這里,我填寫了svn倉庫中的標準的tags目錄。 #### 提交代碼 接著,確保你的所有代碼都提交了,如果你有未提交代碼,release插件會報錯,既然你要發布版本了,就表示代碼是穩定的,所以要么要么把代碼提交了,要么把本地的更改拋棄了。 #### 開始工作 現在,屏住呼吸,執行: ~~~ mvn release:prepare ~~~ 執行過程中,你會遇到這樣的提示: *What is the release version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.0: :* ——“你想將1.0-SNAPSHOT發布為什么版本?默認是1.0。”我要的就是1.0,直接回車。 *What is SCM release tag or label for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) myapp-1.0: :* ——“發布的tag標簽名稱是什么?默認為myapp-1.0。”我還是要默認值,直接回車。 *What is the new development version for "Unnamed - org.myorg:myapp:jar:1.0-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :* ——“主干上新的版本是什么?默認為1.1-SNAPSHOT。”哈,release插件會自動幫我更新版本到1.1-SNAPSHOT,很好,直接回車。 然后屏幕刷阿刷,maven在build我們的項目,并進行了一些svn操作,你可以仔細查看下日志。 那么結果是什么呢?你可以瀏覽下svn倉庫: - 我們多了一個tag:https://192.168.1.100:8443/svn/myapp/tags/myapp-1.0/,這就是需要發布的版本1.0。 - 再看看trunk中的POM,其版本自動升級成了1.1-SNAPSHOT。 這不正是我們想要的么?等等,好像缺了點什么,對了,1.0還沒有發布到倉庫中呢。 再一次屏住呼吸,執行: ~~~ mvn release:perform ~~~ maven-release-plugin會自動幫我們簽出剛才打的tag,然后打包,分發到遠程Maven倉庫中,至此,整個版本的升級,打標簽,發布等工作全部完成。我們可以在遠程Maven 倉庫中看到正式發布的1.0版本。 這可是自動化的 ,正式的 版本發布! ### Maven的版本規則 前面我們提到了SNAPSHOT和Release版本的區別,現在看一下,為什么要有1.0,1.1,1.1.1這樣的版本,這里的規則是什么。 Maven主要是這樣定義版本規則的: ~~~ <主版本>.<次版本>.<增量版本> ~~~ 比如說1.2.3,主版本是1,次版本是2,增量版本是3。 主版本一般來說代表了項目的重大的架構變更,比如說Maven 1和Maven 2,在架構上已經兩樣了,將來的Maven 3和Maven 2也會有很大的變化。次版本一般代表了一些功能的 增加或變化,但沒有架構的變化,比如說Nexus 1.3較之于Nexus 1.2來說,增加了一系列新的或者改進的功能(倉庫鏡像支持,改進的倉庫管理界面等等),但從大的架構上 來說,1.3和1.2沒什么區別。至于增量版本,一般是一些小的bug fix,不會有重大的功能變化。 一般來說,在我們發布一次重要的版本之后,隨之會開發新的版本,比如說,myapp-1.1發布之后,就著手開發myapp-1.2了。由于myapp-1.2有新的主要功能的添加和變化, 在發布測試前,它會變得不穩定,而myapp-1.1是一個比較穩定的版本,現在的問題是,我們在myapp-1.1中發現了一些bug(當然在1.2中也存在),為了能夠在段時間內修復 bug并仍然發布穩定的版本,我們就會用到分支(branch),我們基于1.1開啟一個分支1.1.1,在這個分支中修復bug,并快速發布。這既保證了版本的穩定,也能夠使bug得到 快速修復,也不同停止1.2的開發。只是,每次修復分支1.1.1中的bug后,需要merge代碼到1.2(主干)中。 上面講的就是我們為什么要用增量版本。 ### 實戰分支 目前我們trunk的版本是1.1-SNAPSHOT,其實按照前面解釋的版本規則,應該是1.1.0-SNAPSHOT。 現在我們想要發布1.1.0,然后將主干升級為1.2.0-SNAPSHOT,同時開啟一個1.1.x的分支,用來修復1.1.0中的bug。 首先,在發布1.1.0之前,我們創建1.1.x分支,運行如下命令: ~~~ mvn release:branch -DbranchName=1.1.x -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false ~~~ 這是maven-release-plugin的branch目標,我們指定branch的名稱為1.1.x,表示這里會有版本1.1.1, 1.1.2等等。updateBranchVersions=true的意思是在分支中更新版本,而 updateWorkingCopyVersions=false是指不更改當前工作目錄(這里是trunk)的版本。 在運行該命令后,我們會遇到這樣的提示: *What is the branch version for "Unnamed - org.myorg:myapp:jar:1.1-SNAPSHOT"? (org.myorg:myapp) 1.1-SNAPSHOT: :* ——"分支中的版本號是多少?默認為1.1-SNAPSHOT" 這時我們想要的版本是1.1.1-SNAPSHOT,因此輸入1.1.1-SNAPSHOT,回車,maven繼續執行直至結束。 接著,我們瀏覽svn倉庫,會看到這樣的目錄:https://192.168.1.100:8443/svn/myapp/branches/1.1.x/,打開其中的POM文件,其版本已經是1.1.1-SNAPSHOT。 分支創建好了,就可以使用release:prepare和release:perform為1.1.0打標簽,升級trunk至1.2.0-SNAPSHOT,然后分發1.1.0。 至此,一切OK。 ### 小結 本文講述了如何使用Maven結合svn進行版本管理。解釋了Maven中SNAPSHOT版本的來由,以及Maven管理版本的規則。并結合SCM的tag和branch概念展示了如何使用 maven-release-plugin發布版本,以及創建分支。本文涉及的內容比較多,且略顯復雜,不過掌握版本管理的技巧對于項目的正規化管理來說十分重要。Maven為我們提供了一 些一套比較成熟的機制,值得掌握。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看