關於我們
在1C,我們開發的不僅是一個平台
條目
我們最常使用 Maven 作為 Java 應用程式的建置系統,在這篇短文中,我們想談談我們在組織開發過程中必須面對的問題之一,以及幫助我們克服這個問題的方法問題。
先決條件和工作流程
由於我們的 Maven 專案開發的特殊性,我們使用了相當多的模組、依賴項和子專案。 一棵樹中的pom檔案數量可以是幾十甚至上百個。
看起來:沒什麼大不了的,他們創建了一次就忘了。 如果您需要一次更改或添加所有文件中的某些內容,編輯器和 IDE 中有很多方便的工具。 pom.xml 最常見的常規變更是什麼? 我們認為專案版本和依賴項發生了變化。 也許有人會對此提出異議,但這正是我們的情況。 原因在於,與核心一起,我們同時開發了許多自己的程式庫,為了建立和測試結果的持續可重複性,使用快照對我們來說似乎不是一種方便的方法。 因此,有必要在每次建置時提高專案的版本號。
此外,開發人員有時需要建立自己的庫分支並根據所有依賴項檢查其功能,為此他必須手動更改所有依賴項的版本。
初步解決方案
由於如此頻繁和多個版本更改,我希望簡化 CI 內的流程並實現自動化。 這時,一個方便的、眾所周知的插件就可以派上用場了。 版本-maven-插件 - 連接並啟動它
mvn -N 版本:設定-DnewVersion=2.0.1
Maven 會做它應該做的一切:它將從上到下貫穿層次結構,替換所有版本 - 美! 現在剩下的就是提出 Pull Request,同事會審核更改,然後你就可以快速加入主幹了。 迅速地? 不管怎樣。 幾百個 pom.xml 供審查,這還不包括程式碼。 此外,沒有人能夠避免與如此大量的更改文件發生合併衝突。 這裡應該注意的是,在 CI 過程中,版本變更會隨著功能的變更自動發生,而不是單獨發生。
新功能
有一段時間我們平靜下來,聽天由命,我們就這樣生活,直到來自
mvn -Drevision=2.0.0 乾淨包
系統屬性值優先於中定義的值性能>.
父母
4.0.0
org.apache
阿帕契
18
org.apache.maven.ci
ci-parent
第一個 CI 友善型
${修訂}${sha1}${變更清單}
...
1.3.1
-快照
後裔
4.0.0
org.apache.maven.ci
ci-parent
${修訂}${sha1}${變更清單}
org.apache.maven.ci
慈子
...
如果你想建立版本 2.0.0-SNAPSHOT,那麼只需使用
mvn -Drevision=2.0.0 乾淨包
如果你想發布,那麼只需重置 SNAPSHOT
mvn -Dchangelist=清理包
*以上例子取自
無情的現實
一切都很好,很健康,是時候感到滿足感了,但沒有。 事實證明,此方法不適用於安裝和部署,因為它不會在儲存庫中發布的工件的描述中被替換 ${修訂} 其含義和 maven 將不再理解它的全部內容。
org.apache
阿帕契
${修訂}
隧道盡頭的一盞燈
我們需要尋找解決問題的方法。 本來可以挽救局面
為項目新增插件
org.codehaus.mojo
扁平化 Maven 插件
1.1.0
真的
僅解析 CiFriendlies
壓扁
流程資源
壓扁
展平.清潔
乾淨的
乾淨的
完成!
好結局
從現在開始,為了更改整個專案的版本並讓所有依賴項都知道它,我們只需要編輯該元素調整> 僅在根中 pom.xml。 這些具有相同更改的文件不是一百個或兩個到達審查的,而是一個。 嗯,沒必要用 版本-maven-插件.
來源: www.habr.com