最近遇到一個關(guān)于 jar 包管理的疑問。記錄下，說不定哪天遇到最佳實踐。
有一個工程 X，對應(yīng)一個 jar 包，用于做接口定義，當(dāng)前版本為 1.0.0。
佳佳、包包兩人，分別要在工程 X 中定義新方法 A 和 B。
并且在項目 P 中實現(xiàn)方法。
佳佳定義了新的方法 A，將 jar 包版本升級到 1.0.1-SNAPSHOT，deploy 到倉庫。
包包也定義了新的方法 B，也將 jar 包版本升級到 1.0.1-SNAPSHOT，deploy 到了倉庫。
佳佳在某次重啟的時候，發(fā)現(xiàn) IDE 提示沒有實現(xiàn)方法 B。
于是，佳佳和包包準(zhǔn)備協(xié)商一種 jar 包管理的方法。
考慮以下幾點：
兩人不能共用一個版本的 jar 包。佳佳的程序只需要關(guān)注方法 A，而不可能實現(xiàn)包包需要實現(xiàn)的 method B。
考慮到兩人的代碼將在開發(fā)環(huán)境共存一段時間，又需要將兩人的方法定義統(tǒng)一在一個 jar 包內(nèi)，部署到倉庫，供開發(fā)環(huán)境的項目 P 使用。
考慮到上線順序不定，不能隨意將 jar 包升級到某個正式版。
暫時想到可行的辦法：
在本地，大家有自個的環(huán)境。不需要考慮代碼層面的沖突，只需要關(guān)注 jar 包 SNAPSHOT 版本是否沖突。因為 SNAPSHOT 是可變的。當(dāng)前包版本為 1.0.0 時，佳佳打包版本為 1.0.1.jiajia-SNAPSHOT；包包則打包為 1.0.1.baobao-SNAPSHOT。
涉及到聯(lián)調(diào)和實現(xiàn)，可直接當(dāng)該 jar 包提供給使用方。因為佳佳的聯(lián)調(diào)方只需關(guān)注 1.0.1.jiajia-SNAPSHOT 中提供的方法 A。
佳佳首先在項目 P 中實現(xiàn)了方法 A ，并將代碼推到開發(fā) dev 分支，引用的 jar 包版本為 1.0.1.jiajia-SNAPSHOT。
包包在項目 P 中引用 1.0.1.jiajia-SNAPSHOT，當(dāng)需要將項目 P 的代碼推到 dev 分支時，發(fā)現(xiàn)沖突。從 jar 包版本得知，佳佳也在同時開發(fā)。
此時，包包在工程 X 中新建解決沖突分支，解決沖突，新打一個包為 1.0.1.conflict-SNAPSHOT，并在項目 P 中引用該包。順利部署到開發(fā)環(huán)境。
涉及到?jīng)_突解決，兩人在工程 X 中定義完新方法后，需要將對應(yīng)的分支推到主倉庫讓對方看到。并使用明顯的分支名稱，方便對方解決沖突。
需要上線時候，假設(shè)包包先上線。拉取工程 X master 分支的代碼，防止佳佳已經(jīng)上線，得知最新版本沒變，則在工程 X 中打包 1.0.1，項目 P 引用 1.0.1 順利上線。并將代碼合并到工程 X 的 master 分支。
佳佳上線時，首先拉取工程 X 的 master 分支，發(fā)現(xiàn)1.0.1被占用，則使用最新版本1.0.2。
