本申請(qǐng)涉及計(jì)算機(jī)軟件技術(shù)領(lǐng)域，尤其涉及一種升級(jí)方法及裝置。

背景技術(shù)：

Maven(項(xiàng)目構(gòu)建管理)是基于POM(項(xiàng)目對(duì)象模型)，可以通過(guò)一小段描述信息來(lái)管理項(xiàng)目的構(gòu)建，報(bào)告和文檔的軟件項(xiàng)目管理工具。Maven包括SNAPSHOT快照倉(cāng)庫(kù)和release發(fā)布倉(cāng)庫(kù)。SNAPSHOT快照倉(cāng)庫(kù)用于保存開(kāi)發(fā)過(guò)程中的不穩(wěn)定版本，release正式倉(cāng)庫(kù)則是用來(lái)保存穩(wěn)定的發(fā)行版本。SNAPSHOT是個(gè)快照并有隨時(shí)被更新覆蓋的情況存在，導(dǎo)致容易發(fā)生線上故障，但有些Maven工程中會(huì)直接或者間接依賴SNAPSHOT包，這就需要對(duì)依賴鏈路進(jìn)行去SNAPSHOT包的工作，即將依賴SNAPSHOT包的鏈路升級(jí)為依賴release包的鏈路。

目前，如果要推動(dòng)一個(gè)Maven工程進(jìn)行去SNAPSHOT包的工作，開(kāi)發(fā)方需要針對(duì)每個(gè)jar包一層層的推動(dòng)上層業(yè)務(wù)去做變更，比如以下的鏈路A-＞B-＞C-SNAPSHOT-＞D-＞E-SNAPSHOT，對(duì)當(dāng)前推動(dòng)方A來(lái)說(shuō)，他需要推動(dòng)B不能依賴任何SNAPSHOT版本，也就意味著B(niǎo)需要推動(dòng)業(yè)務(wù)方C去發(fā)布C’版本，同理C需要推動(dòng)D，D需要推動(dòng)E，及一層層推動(dòng)業(yè)務(wù)方去升級(jí)release包，中間任何一個(gè)環(huán)節(jié)都缺一不可，直到整條鏈路變更SNAPSHOT包，得到一條升級(jí)鏈路。

但由于Maven整條鏈路上會(huì)很長(zhǎng)，可能有10甚至更多的節(jié)點(diǎn)存在，當(dāng)前沒(méi)有一個(gè)自動(dòng)的方案可以解決去SNAPSHOT包過(guò)程，全部都是人工的變更， 在升級(jí)依賴鏈路的時(shí)候，需要一層層的推動(dòng)業(yè)務(wù)方去升級(jí)release包，溝通成本很大，解決問(wèn)題也很復(fù)雜。

技術(shù)實(shí)現(xiàn)要素：

本申請(qǐng)實(shí)施例提出了一種升級(jí)方法及裝置，以解決現(xiàn)有技術(shù)中在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的技術(shù)問(wèn)題。

本申請(qǐng)實(shí)施例提供了一種升級(jí)方法，包括：

獲取當(dāng)前項(xiàng)目構(gòu)建管理Maven工程的第一依賴鏈路，該第一依賴鏈路中包括待變更包；

獲取所述待變更的包轉(zhuǎn)換為升級(jí)包的映射規(guī)則；

根據(jù)該映射規(guī)則修改該第一依賴鏈路，得到第二依賴鏈路。

本申請(qǐng)實(shí)施例提供了一種升級(jí)裝置，包括：

依賴鏈路獲取模塊，用于獲取當(dāng)前項(xiàng)目構(gòu)建管理Maven工程的第一依賴鏈路，該第一依賴鏈路中包括待變更包；

依賴鏈路解析模塊，用于獲取所述待變更包轉(zhuǎn)換為升級(jí)包的映射規(guī)則；

依賴鏈路轉(zhuǎn)換模塊，用于根據(jù)所述映射規(guī)則，修改第一依賴鏈路，得到第二依賴鏈路。

有益效果如下：

由于本申請(qǐng)實(shí)施例所提供的技術(shù)方案通過(guò)解析當(dāng)前Maven工程的依賴鏈路及待變更包的映射規(guī)則，根據(jù)映射規(guī)則對(duì)初始的依賴鏈路進(jìn)行修改，從而得到穩(wěn)定的依賴鏈路，實(shí)現(xiàn)了對(duì)初始依賴鏈路的升級(jí)，解決了在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的問(wèn)題。

附圖說(shuō)明

下面將參照附圖描述本申請(qǐng)的具體實(shí)施例，其中：

圖1示出了本申請(qǐng)實(shí)施例中一種升級(jí)方法實(shí)施的流程示意圖；

圖2示出了本申請(qǐng)實(shí)施例中又一種升級(jí)方法實(shí)施的流程示意圖；

圖3示出了本申請(qǐng)實(shí)施例中又一種升級(jí)方法實(shí)施的流程示意圖；

圖4示出了本申請(qǐng)實(shí)施例中一種升級(jí)裝置的結(jié)構(gòu)示意圖；

圖5示出了本申請(qǐng)實(shí)施例中又一種升級(jí)裝置的結(jié)構(gòu)示意圖。

具體實(shí)施方式

為了使本申請(qǐng)的技術(shù)方案及優(yōu)點(diǎn)更加清楚明白，以下結(jié)合附圖對(duì)本申請(qǐng)的示例性實(shí)施例進(jìn)行進(jìn)一步詳細(xì)的說(shuō)明，顯然，所描述的實(shí)施例僅是本申請(qǐng)的一部分實(shí)施例，而不是所有實(shí)施例的窮舉。并且在不沖突的情況下，本說(shuō)明中的實(shí)施例及實(shí)施例中的特征可以互相結(jié)合。

發(fā)明人在發(fā)明過(guò)程中注意到：在現(xiàn)有的Maven工程中，SNAPSHOT有隨時(shí)被更新覆蓋的情況存在，導(dǎo)致容易發(fā)生線上故障，而有些Maven工程中會(huì)直接或者間接依賴SNAPSHOT包，這就需要對(duì)依賴鏈路進(jìn)行去SNAPSHOT包的工作，以升級(jí)現(xiàn)有的依賴鏈路。本實(shí)施例中提到的當(dāng)前Maven工程是指系統(tǒng)當(dāng)前正在執(zhí)行的Maven工程。

基于此，本申請(qǐng)實(shí)施例提出了一種升級(jí)方法及裝置，下面進(jìn)行說(shuō)明。

圖1示出了本申請(qǐng)實(shí)施例提供的一種升級(jí)方法，如圖1所示，包括：

步驟101、獲取當(dāng)前項(xiàng)目構(gòu)建管理Maven工程的第一依賴鏈路，該第一依賴鏈路中包括待變更包；

步驟102、獲取待變更包轉(zhuǎn)換為升級(jí)包的映射規(guī)則；

步驟103、根據(jù)該映射規(guī)則修改該第一依賴鏈路，得到第二依賴鏈路。

本實(shí)施例中待變更包包括但不限于SNAPSHOT包，對(duì)此本實(shí)施例中不做具體限定。

在另一種可能的實(shí)施方式中，獲取當(dāng)前Maven工程的第一依賴鏈路關(guān)系，包括：

通過(guò)Maven插件獲取當(dāng)前Maven工程的pom(項(xiàng)目對(duì)象模型)文件；

解析所述pom文件，依次獲取所述當(dāng)前Maven工程的各個(gè)鏈路節(jié)點(diǎn)，得到所述當(dāng)前Maven工程的第一依賴鏈路。

在另一種可能的實(shí)施方式中，所述獲取將所述待變更包轉(zhuǎn)換為升級(jí)包的映射規(guī)則，包括：

解析出所述第一依賴鏈路中的待變更包；

獲取所述待變更包的映射規(guī)則，所述映射規(guī)則包括：如果所述待變更包中包括預(yù)設(shè)后綴名，則將所述待變更的包的版本號(hào)的后綴名對(duì)應(yīng)修改為升級(jí)包的后綴名，如果所述待變更包中不包括所述預(yù)設(shè)后綴名，則在所述待變更包后添加所述升級(jí)包的后綴名；

根據(jù)所述待變更包的映射規(guī)則，確認(rèn)與所述待變更包對(duì)應(yīng)的升級(jí)包的后綴名。

在另一種可能的實(shí)施方式中，根據(jù)所述映射規(guī)則修改所述第一依賴鏈路，得到第二依賴鏈路，包括：

獲取所述第一依賴鏈路關(guān)聯(lián)的jar(歸檔文件)對(duì)應(yīng)的pom文件；

解析出所述jar對(duì)應(yīng)的pom文件的屬性列表，并將所述當(dāng)前Maven工程的內(nèi)置變量添加到所述屬性列表中，所述當(dāng)前Maven工程的內(nèi)置變量包括：組織標(biāo)識(shí)、項(xiàng)目標(biāo)識(shí)和版本號(hào)；

根據(jù)所述映射規(guī)則修改所述jar對(duì)應(yīng)的pom文件屬性列表中的版本號(hào)，得到第二依賴鏈路。

在另一種可能的實(shí)施方式中，根據(jù)所述映射規(guī)則修改所述jar對(duì)應(yīng)的pom文件屬性列表中的版本號(hào)，得到第二依賴鏈路之前，還包括：

獲取所述第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom文件的所有父pom列表；

判斷是否有需要修改的父pom列表，如果是，則根據(jù)所述映射規(guī)則修改所述需要修改的父pom列表下每個(gè)pom文件屬性列表中的版本號(hào)。

在另一種可能的實(shí)施方式中，所述方法還包括：

驗(yàn)證所述第二依賴鏈路的MD5(Message Digest Algorithm，消息摘要算法 第五版)值與所述第一鏈路的MD5值是否相同，如果是，則將所述第二依賴鏈路存儲(chǔ)到Maven倉(cāng)庫(kù)中。

在另一種可能的實(shí)施方式中，驗(yàn)證所述第二依賴鏈路的MD5值與所述第一鏈路的MD5值是否相同，包括：

獲取所述第一依賴鏈路中需要修改的jar，計(jì)算所述第一鏈路中需要修改的jar的第一MD5值；

獲取所述第二依賴鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改的jar，計(jì)算所述第二鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改后的jar的第二MD5值；

判斷所述第一MD5值與所述第二MD5值是否相同，如果是，則確認(rèn)所述第二依賴鏈路的MD5值與所述第一鏈路的MD5值相同。

有益效果：本申請(qǐng)實(shí)施例所提供的技術(shù)方案通過(guò)解析當(dāng)前Maven工程的依賴鏈路及待變更包的映射規(guī)則，根據(jù)映射規(guī)則對(duì)初始的依賴鏈路進(jìn)行修改，從而得到穩(wěn)定的依賴鏈路，實(shí)現(xiàn)了對(duì)初始依賴鏈路的升級(jí)，解決了在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的問(wèn)題。

參見(jiàn)圖2，本申請(qǐng)的又一實(shí)施例中提供了一種升級(jí)方法，該實(shí)施例在上述實(shí)施例的基礎(chǔ)上給出了一個(gè)具體的實(shí)施方式，在執(zhí)行當(dāng)前Maven工程時(shí)，可以自動(dòng)執(zhí)行如下步驟，無(wú)需人工參與。如圖2所示，該方法包括：

步驟201、獲取當(dāng)前Maven工程的第一依賴鏈路。

本實(shí)施例中，設(shè)置Maven插件，在執(zhí)行Maven工程時(shí)，調(diào)用該插件，通過(guò)該插件解析出當(dāng)前Maven工程的pom文件(即pom.xml文件)，然后依次獲取當(dāng)前Maven工程的各個(gè)鏈路節(jié)點(diǎn)，得到當(dāng)前Maven工程的第一依賴鏈路。具體方法包括：

步驟1)通過(guò)Maven插件獲取當(dāng)前Maven工程的pom文件；

步驟2)解析該pom文件，獲取當(dāng)前Maven工程依賴的第1節(jié)點(diǎn)；

步驟3)通過(guò)Maven插件對(duì)該第1節(jié)點(diǎn)進(jìn)行解析，獲得所述第1節(jié)點(diǎn)的解 析結(jié)果；

步驟4)判斷該解析結(jié)果中是否有第1節(jié)點(diǎn)的依賴節(jié)點(diǎn)，如果沒(méi)有，則將該第1節(jié)點(diǎn)做為當(dāng)前Maven工程的最后一個(gè)依賴節(jié)點(diǎn)，如果有，則將該第1節(jié)點(diǎn)的依賴節(jié)點(diǎn)作為第1節(jié)點(diǎn)，重復(fù)執(zhí)行步驟3)-4)，直到找到當(dāng)前Maven工程的最后一個(gè)依賴節(jié)點(diǎn)，得到當(dāng)前Maven工程的第一依賴鏈路。

其中，pom文件是Maven項(xiàng)目中的文件。在一個(gè)Maven工程中，不僅僅是一堆包含代碼的文件，還包含pom文件，該文件用于管理：源代碼、配置文件、開(kāi)發(fā)者的信息和角色、問(wèn)題追蹤系統(tǒng)、組織標(biāo)識(shí)、項(xiàng)目授權(quán)、項(xiàng)目的依賴關(guān)系等等，此處與現(xiàn)有技術(shù)中對(duì)pom文件的描述一致，在此本實(shí)施例中不再贅述。

由于pom文件中存儲(chǔ)有項(xiàng)目的依賴關(guān)系，所以通過(guò)對(duì)Maven工程中pom文件的解析，就能夠得出該工程的依賴關(guān)系，一個(gè)jar(歸檔文件)一條數(shù)據(jù)鏈路，每個(gè)節(jié)點(diǎn)的數(shù)據(jù)形式以GroupId(組織標(biāo)識(shí))：artifactId(項(xiàng)目標(biāo)識(shí))：Version(版本號(hào))組合，比如鏈路：

com.tmall：sak-app：war：1.0-SNAPSHOT-＞com.tmall：sak-biz-common：jar：1.0-SNAPSHOT-＞com.taobao.carts：carts-client：jar：1.0.13-＞com.taobao.trade：tradebase：jar：1.0.37-＞com.taobao.trade.platform：tp-client：jar：1.4.32-＞com.taobao.misccenter：misccenter-client：jar：1.5.3.2_ladder-SNAPSHOT-＞com.taobao.tradesecurity：ts-client：jar：1.0.1-SNAPSHOT-＞com.taobao.sharereport：share-report-common：jar：1.5.1-SNAPSHOT。

其中，com.tmall：sak-app：war：1.0-SNAPSHOT、com.tmall：sak-biz-common：jar：1.O-SNAPSHOT、com.taobao.trade：tradebase：jar：1.0.37等為依賴鏈路中的節(jié)點(diǎn)，其中包含SNAPSHOT的包是待變更包。在具體解析的過(guò)程中，通過(guò)Maven插件獲取當(dāng)前工程的pom文件，從該文件中解析出第1個(gè)節(jié)點(diǎn)com.tmall：sak-app：war：1.0-SNAPSHOT，然后對(duì)該節(jié)點(diǎn)進(jìn)行解析，對(duì)解析結(jié)果進(jìn)行分析，確認(rèn)是否有該節(jié)點(diǎn)的依賴節(jié)點(diǎn)，如解析出該節(jié)點(diǎn)的依賴節(jié)點(diǎn)為com.tmall：sak-biz-common：jar：1.0-SNAPSHOT，則繼續(xù)對(duì)該節(jié)點(diǎn)進(jìn)行解析，直 到解析到com.taobao.sharereport：share-report-common：jar：1.5.1-SNAPSHOT節(jié)點(diǎn)，發(fā)現(xiàn)其沒(méi)有后續(xù)依賴節(jié)點(diǎn)，則完成依賴鏈路的解析，得到如上的依賴節(jié)點(diǎn)。

另外，值得注意的是，本實(shí)施例中一個(gè)jar對(duì)應(yīng)一條依賴鏈路，如果當(dāng)前Maven工程只包含一個(gè)jar，則第一依賴鏈路包括一條，但是如果當(dāng)前Maven工程包括多個(gè)jar，則第一依賴鏈路指代多條，每條鏈路均執(zhí)行如下步驟，對(duì)此本實(shí)施例中不再贅述。

步驟202、獲取待變更包轉(zhuǎn)換為升級(jí)包的映射規(guī)則。

具體應(yīng)用中，會(huì)對(duì)于不同的待變更包可以預(yù)先設(shè)定多個(gè)映射規(guī)則，包括：如果所述待變更包中包括預(yù)設(shè)后綴名，則將所述待變更的包的版本號(hào)的后綴名對(duì)應(yīng)修改為升級(jí)包的后綴名，如果所述待變更包中不包括所述預(yù)設(shè)后綴名，則在所述待變更包后添加所述升級(jí)包的后綴名。例如，每個(gè)工程的SNAPSHOT包轉(zhuǎn)release包都統(tǒng)一有如下規(guī)則，version以-SNSPSHOT結(jié)尾的，將-SNAPSHOT改為-mysuffix，如果version以.SNAPSHOT結(jié)尾的，那統(tǒng)一將.SNAPSHOT改為-mysuffix，其他的統(tǒng)一追加-mysuffix，比如version為2.0.0，那么改后的版本為2.0.0-mysuffix。對(duì)于其他類型的待變更包也可以設(shè)置其他對(duì)應(yīng)的映射規(guī)則，其中映射規(guī)則可以存儲(chǔ)在Maven倉(cāng)庫(kù)中，也可以單獨(dú)創(chuàng)建文件家存儲(chǔ)，對(duì)此本實(shí)施例中不做具體限定。

本步驟中，在獲取到第一鏈路后，解析出第一鏈路中的待變更包，在多個(gè)映射規(guī)則中找到與該待變更包對(duì)應(yīng)的映射規(guī)則，根據(jù)其對(duì)應(yīng)的映射規(guī)則，確認(rèn)與其對(duì)應(yīng)的升級(jí)包的后綴名，如與SNAPSHOT包對(duì)應(yīng)的升級(jí)包為release包，解析出升級(jí)包的后綴名，對(duì)應(yīng)存儲(chǔ)待變更包與其對(duì)應(yīng)的升級(jí)包的映射規(guī)則。

本實(shí)施例中通過(guò)修改后綴名，將待變更不穩(wěn)定包轉(zhuǎn)換為穩(wěn)定包，這樣即使有新的不穩(wěn)定包時(shí)，修改過(guò)后綴名的包也不會(huì)被覆蓋，從而保證了鏈路的穩(wěn)定性。

值得注意的是，在本步驟中，只是獲取對(duì)應(yīng)修改的映射規(guī)則，不具體執(zhí)行包的修改。且本實(shí)施例中以去SNAPSHOT包，將其轉(zhuǎn)換為release包為例，但 在不同的應(yīng)用場(chǎng)景下，并不局限于此一種實(shí)施方式，在其它實(shí)施方式中對(duì)應(yīng)的映射規(guī)則也可不同，本實(shí)施例對(duì)此不做具體限定。

步驟203、獲取第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom的所有父pom列表，判斷是否有需要修改的父pom列表，如果是，則執(zhí)行步驟204，否則執(zhí)行步驟205。

本實(shí)施例中，如果存在多條依賴鏈路，則遍歷依賴鏈路中的每個(gè)jar的pom文件，獲取當(dāng)前jar對(duì)應(yīng)的pom的所有父pom列表，其中父pom列表的形式為GroupId：artifactId：version。確認(rèn)父pom列表中是否有待變更包，如SNAPSHOT包，如果有，則確認(rèn)該父pom列表需要修改，如果沒(méi)有待變更包，則不需要修改。

步驟204、根據(jù)映射規(guī)則修改需要修改的父pom列表下每個(gè)pom文件屬性列表中的版本號(hào)。

本步驟中，獲取需要修改的父pom列表下的所有pom文件，解析出每個(gè)pom文件的屬性列表，并將當(dāng)前Maven工程的內(nèi)置變量添加到該屬性列表中。具體的，對(duì)于需要修改的父pom列表，從頂層pom依次往下遍歷，獲取每個(gè)pom的properties(屬性列表)，元素為//project/prperties，并將Maven工程自帶的內(nèi)置變量追加到該屬性列表中，比如${project.groupId}，${project.artifactid}，${project.version}等。

值得注意的是，在添加變量值之后，需要將該變量依次解析為常量值，具體的解析過(guò)程與現(xiàn)有技術(shù)中一樣，本實(shí)施例中不再贅述。

依據(jù)解析出來(lái)屬性列表，變更當(dāng)前pom文件中的version，其中version的變更按照步驟202中獲取的映射規(guī)則進(jìn)行替換，即將version以-SNSPSHOT結(jié)尾的，將-SNAPSHOT改為-mysuffix，如果version以.SNAPSHOT結(jié)尾的，那統(tǒng)一將.SNAPSHOT改為-mysuffix，其他的統(tǒng)一追加-mysuffix。

在一種可能的實(shí)施例中，GroupId可以從父pom里繼承過(guò)來(lái)，也就是說(shuō)，如果一個(gè)當(dāng)前pom它有一個(gè)父pom，那么這個(gè)當(dāng)前pom是不需要定義GroupId 的，因?yàn)镚roupId會(huì)從父pom繼承過(guò)來(lái)。那么在修改當(dāng)前pom的時(shí)候，如果發(fā)現(xiàn)GroupId是空的，為了使流程更清晰，可選地，在當(dāng)前pom中添加其對(duì)應(yīng)的父pom的GroupId。因此在對(duì)當(dāng)前pom文件進(jìn)行變更時(shí)，如遇到上述情況，可依次變更pom文件中的如下三個(gè)元素<groupId>，<artifacfId>，<version>。其中，<artifactId>是不需要修改的，直接保留，可能修改的為<groupId>，必須修改的為<version>。

值得注意的是，本實(shí)施例中步驟203-204是可選地，在實(shí)際執(zhí)行過(guò)程中可以不對(duì)父pom列表進(jìn)行修改，而直接執(zhí)行步驟205，對(duì)此本實(shí)施例中不做具體限定。

步驟205、獲取第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom文件，獲取該pom文件的屬性列表，根據(jù)映射規(guī)則修改該pom文件屬性列表中的版本號(hào)，得到第二依賴鏈路。

具體的，獲取第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom文件的屬性列表的方法與獲取父pom列表下pom文件的方法類似，包括：解析出該pom文件的屬性列表，并將當(dāng)前Maven工程的內(nèi)置變量添加到所述屬性列表中，當(dāng)前Maven工程的內(nèi)置變量包括：組織標(biāo)識(shí)、項(xiàng)目標(biāo)識(shí)和版本號(hào)。

本步驟中，依據(jù)解析出來(lái)屬性列表，依次變更<groupId>，<artifactId>，<version>，其中version的變更按照步驟202中獲取的映射規(guī)則進(jìn)行替換此處與父pom列表下pom文件的修改類似，對(duì)此本實(shí)施例中不再贅述。

如步驟201中示范的鏈路，升級(jí)后轉(zhuǎn)換為com.tmall：sak-app：war：1.0-mysuffix-＞com.tmall：sak-biz-common：jar：1.0-mysuffix-＞com.taobao.carts：carts-client：jar：1.0.13-mysuffix-＞com.taobao.trade：tradebase：jar：1.0.37-mysuffix-＞com.taobao.trade.platform：tp-client：jar：1.4.32-mysuffix-＞com.taobao.misccenter：misccenter-client：jar：1.5.3.2_ladder-mysuffix-＞com.taobao.tradesecurity：ts-client：jar：1.0.1-mysuffix-＞com.taobao.sharereport：share-report-common：jar：1.5.1-mysuffix。

在本實(shí)施例中，如果依賴鏈路中的某個(gè)節(jié)點(diǎn)中不包括待變更包，則不需要要進(jìn)行轉(zhuǎn)換。如，依賴鏈路為A-＞B-＞C-SNAPHOST-＞D-＞E-SNAPSHOT-＞F-＞ G，那么最終產(chǎn)生的結(jié)果會(huì)有如下幾個(gè)包：A-mysuffix-＞B-mysuffix-＞C-mysuffix-＞D-mysuffix-＞E-mysuffix-＞F-＞G。其中A，B，C，D，E生成了新的5個(gè)包，F(xiàn)，G因?yàn)楹竺鏇](méi)有依賴任何的SNAPSHOT版本，所以不需要生成新的包。

有益效果：本實(shí)施例通過(guò)解析當(dāng)前Maven工程的依賴鏈路及待變更包映射規(guī)則，根據(jù)映射規(guī)則對(duì)初始的依賴鏈路進(jìn)行修改，從而得到穩(wěn)定的依賴鏈路，實(shí)現(xiàn)了對(duì)初始依賴鏈路的升級(jí)，解決了在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的問(wèn)題。

參見(jiàn)圖3，本申請(qǐng)的又一實(shí)施例中提供了一種升級(jí)方法，該方法是對(duì)圖2所示的實(shí)施例的實(shí)施細(xì)節(jié)的具體優(yōu)化，如圖3所示，該方法包括：

步驟301、獲取當(dāng)前Maven工程的第一依賴鏈路，將該依賴鏈路的相關(guān)信息存儲(chǔ)到第一文件夾中。

在實(shí)際應(yīng)用中，為了便于對(duì)依賴鏈路的后續(xù)處理，創(chuàng)建相應(yīng)文件夾，將解析出來(lái)的鏈路輸出到第一文件夾中，如輸出到dependency.1ist文件中，對(duì)文件夾的具體命名本實(shí)施例中不做具體限定。其中依賴鏈路的具體解析過(guò)程同上述實(shí)施例中的步驟201類似，對(duì)此本實(shí)施例中不再贅述。

步驟302、對(duì)第一依賴鏈路進(jìn)行解析，得到將該需要變更的包轉(zhuǎn)換為升級(jí)包的映射規(guī)則，并將該映射規(guī)則存儲(chǔ)到第二文件夾中。

本步驟中獲取映射規(guī)則的步驟與上述實(shí)施例中的步驟202類似，對(duì)此本實(shí)施例中不再贅述。在獲取到映射規(guī)則后，將該規(guī)則單獨(dú)存儲(chǔ)到第二文件夾中，如jarRulesMap文件中。

步驟303、獲取第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom的所有父pom列表，將所有的父pom列表存儲(chǔ)到第三文件夾中。

本實(shí)施例中，如果存在多條依賴鏈路，則遍歷依賴鏈路中的每個(gè)jar的pom文件，獲取當(dāng)前jar對(duì)應(yīng)的pom的所有父pom列表，其中父pom列表的形式 為Groupid：artifactId：version，同時(shí)將該父pom列表以Groupid：artifactId：version的數(shù)據(jù)形式存儲(chǔ)到第三文件夾中，如parentPomList中。

步驟304、遍歷第三文件夾中的父列表，判斷是否有需要修改的父pom列表，如果是，則執(zhí)行步驟305，否則執(zhí)行步驟306。

確認(rèn)父pom列表中是否有待變更包，如SNAPSHOT包，如果有，則確認(rèn)該父pom列表需要修改，如果沒(méi)有待變更包，則不需要修改。

步驟305、根據(jù)映射規(guī)則修改需要修改的父pom列表下每個(gè)pom文件屬性列表中的版本號(hào)。

步驟306、獲取第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom文件，獲取該pom文件的屬性列表，根據(jù)映射規(guī)則修改該pom文件屬性列表中的版本號(hào)，得到第二依賴鏈路。

上述本步驟305-306與圖2所示實(shí)施例中的步驟204-205類似，對(duì)此本實(shí)施例中不再贅述。

步驟307、驗(yàn)證第二依賴鏈路的MD5值與第一鏈路的MD5值是否相同，如果是，則執(zhí)行步驟308，否則，返回步驟301。

本步驟中，優(yōu)選地，驗(yàn)證第二依賴鏈路的MD5值與第一鏈路的MD5值是否相同，包括：獲取所述第一依賴鏈路中需要修改的jar，計(jì)算所述第一鏈路中需要修改的jar的第一MD5值；獲取所述第二依賴鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改的jar，計(jì)算所述第二鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改后的jar的第二MD5值；判斷所述第一MD5值與所述第二MD5值是否相同，如果是，則確認(rèn)所述第二依賴鏈路的MD5值與所述第一鏈路的MD5值相同。

本實(shí)施例中，對(duì)于不包含待變更包的節(jié)點(diǎn)不需進(jìn)行修改，所以在進(jìn)行驗(yàn)證時(shí)，只需對(duì)第一依賴鏈路中修改的jar進(jìn)行驗(yàn)證，如依賴鏈路為A-＞B-＞C-SNAPHOST-＞D-＞E-SNAPSHOT-＞F-＞G，修改后的得到第二依賴鏈路為A-mysuffix-＞B-mysuffix-＞C-mysuffix-＞D-mysuffix-＞E-mysuffix-＞F-＞G。其中A，B，C，D，E生成了新的5個(gè)包，F(xiàn)，G因?yàn)楹竺鏇](méi)有依賴任何的 SNAPSHOT版本，所以不需要對(duì)F，G進(jìn)行驗(yàn)證，只需驗(yàn)證A，B，C，D，E的MD5值在第一鏈路中和第二鏈路中是否相同。

在其他的可能實(shí)施方式中，也可以采用現(xiàn)有技術(shù)中的回歸驗(yàn)證方法對(duì)第一依賴鏈路和第二依賴鏈路進(jìn)行驗(yàn)證，對(duì)此本實(shí)施例不做具體限定。

在驗(yàn)證結(jié)果錯(cuò)誤時(shí)，可以彈出錯(cuò)誤指示，提示開(kāi)發(fā)人員重行執(zhí)行步驟301-307，當(dāng)然也可以不彈出錯(cuò)誤指示，直接返回執(zhí)行步驟301，對(duì)此本實(shí)施例中不再贅述。

步驟308、將第二依賴鏈路存儲(chǔ)到Maven倉(cāng)庫(kù)中。

本實(shí)施例中，為了提高效率，減少代碼執(zhí)行的復(fù)雜性，在得到升級(jí)后的第二依賴鏈路后，將該依賴鏈路存儲(chǔ)到Maven倉(cāng)庫(kù)中，這樣在其他Maven工程包含該條鏈路時(shí)，就不需要重新升級(jí)，可以直接調(diào)用。

有益效果：本實(shí)施例通過(guò)解析當(dāng)前Maven工程的依賴鏈路及待變更包映射規(guī)則，根據(jù)映射規(guī)則對(duì)初始的依賴鏈路進(jìn)行修改，從而得到穩(wěn)定的依賴鏈路，實(shí)現(xiàn)了對(duì)初始依賴鏈路的升級(jí)，解決了在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的問(wèn)題。另外本實(shí)施例中通過(guò)文件夾對(duì)鏈路轉(zhuǎn)換的中間數(shù)據(jù)進(jìn)行管理，明確了中間數(shù)據(jù)的識(shí)別路徑，提高了鏈路升級(jí)的執(zhí)行效率。另一方面，通過(guò)升級(jí)鏈路jar的MD5值，就能夠?qū)ι?jí)鏈路進(jìn)行驗(yàn)證，提升了線上風(fēng)險(xiǎn)的可控性。

基于同一發(fā)明構(gòu)思，本申請(qǐng)實(shí)施例中還提供了一種升級(jí)裝置，由于該裝置解決問(wèn)題的原理與一種升級(jí)方法相似，因此這些裝置的實(shí)施可以參見(jiàn)方法的實(shí)施，重復(fù)之處不再贅述。

如圖4所示，裝置可以包括：依賴鏈路獲取模塊401，依賴鏈路解析模塊402，依賴鏈路轉(zhuǎn)換模塊403。

依賴鏈路獲取模塊401，用于獲取當(dāng)前項(xiàng)目構(gòu)建管理Maven工程的第一依賴鏈路，所述第一依賴鏈路中包括待變更包；

依賴鏈路解析模塊402，用于獲取所述待變更包轉(zhuǎn)換為升級(jí)包的映射規(guī)則；

依賴鏈路轉(zhuǎn)換模塊403，用于根據(jù)所述映射規(guī)則，修改所述第一依賴鏈路，得到第二依賴鏈路。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述依賴鏈路獲取模塊401，包括：

第一獲取單元401a，用于通過(guò)Maven插件獲取當(dāng)前Maven工程的項(xiàng)目對(duì)象模型pom文件；

第一解析單元401b，用于解析所述pom文件，依次獲取所述當(dāng)前Maven工程的各個(gè)鏈路節(jié)點(diǎn)，得到所述當(dāng)前Maven工程的第一依賴鏈路。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述依賴鏈路解析模塊402，包括：

第二解析單元402a，用于解析出所述第一依賴鏈路中的待變更包；

第二獲取單元402b，用于獲取所述待變更包的映射規(guī)則，所述映射規(guī)則包括：如果所述待變更包中包括預(yù)設(shè)后綴名，則將所述待變更的包的版本號(hào)的后綴名對(duì)應(yīng)修改為升級(jí)包的后綴名，如果所述待變更包中不包括所述預(yù)設(shè)后綴名，則在所述待變更包后添加所述升級(jí)包的后綴名；

確認(rèn)單元402c，用于根據(jù)所述待變更包的映射規(guī)則，確認(rèn)與所述待變更包對(duì)應(yīng)的升級(jí)包的后綴名。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述依賴鏈路轉(zhuǎn)換模塊403，包括：

第三獲取單元403a，用于獲取所述第一依賴鏈路關(guān)聯(lián)的歸檔文件jar對(duì)應(yīng)的pom文件；

第三解析單元403b，用于解析出所述jar對(duì)應(yīng)的pom文件的屬性列表，并將所述當(dāng)前Maven工程的內(nèi)置變量添加到所述屬性列表中，所述當(dāng)前Maven工程的內(nèi)置變量包括：組織標(biāo)識(shí)、項(xiàng)目標(biāo)識(shí)和版本號(hào)；

修改單元403c，用于根據(jù)所述映射規(guī)則修改所述jar對(duì)應(yīng)的pom文件屬性列表中的版本號(hào)，得到第二依賴鏈路。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述依賴鏈路轉(zhuǎn)換模塊403，還包括：

第四獲取單元403d，用于在所述修改單元403c得到所述第二依賴鏈路之前，獲取所述第一依賴鏈路關(guān)聯(lián)的jar對(duì)應(yīng)的pom文件的所有父pom列表；

所述修改單元403c還用于判斷是否有需要修改的父pom列表，如果是，則根據(jù)所述映射規(guī)則修改所述需要修改的父pom列表下每個(gè)pom文件屬性列表中的版本號(hào)。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述裝置還包括：

驗(yàn)證模塊404，用于驗(yàn)證所述第二依賴鏈路的消息摘要算法第五版MD5值與所述第一鏈路的MD5值是否相同，如果是，則將所述第二依賴鏈路存儲(chǔ)到Maven倉(cāng)庫(kù)中。

參見(jiàn)圖5，在另一種可能的實(shí)施方式中，所述驗(yàn)證模塊404包括：

第五獲取單元404a，用于獲取所述第一依賴鏈路中需要修改的jar，計(jì)算所述第一鏈路中需要修改的jar的第一MD5值；

第六獲取單元404b，用于獲取所述第二依賴鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改的jar，計(jì)算所述第二鏈路中對(duì)應(yīng)所述第一依賴鏈路中修改后的jar的第二MD5值；

驗(yàn)證單元404c，用于判斷所述第五獲取單元獲取的第一MD5值與所述第六獲取單元獲取的第二MD5值是否相同，如果相同，則確認(rèn)所述第二依賴鏈路的MD5值與所述第一鏈路的MD5值相同。

有益效果：本實(shí)施例通過(guò)解析當(dāng)前Maven工程的依賴鏈路及待變更包映射規(guī)則，根據(jù)映射規(guī)則對(duì)初始的依賴鏈路進(jìn)行修改，從而得到穩(wěn)定的依賴鏈路，實(shí)現(xiàn)了對(duì)初始依賴鏈路的升級(jí)，解決了在Maven工程中不能自動(dòng)升級(jí)依賴鏈路的問(wèn)題。

為了描述的方便，以上所述裝置的各部分以功能分為各種模塊或單元分別描述。當(dāng)然，在實(shí)施本申請(qǐng)時(shí)可以把各模塊或單元的功能在同一個(gè)或多個(gè)軟件 或硬件中實(shí)現(xiàn)。

本領(lǐng)域內(nèi)的技術(shù)人員應(yīng)明白，本申請(qǐng)的實(shí)施例可提供為方法、系統(tǒng)、或計(jì)算機(jī)程序產(chǎn)品。因此，本申請(qǐng)可采用完全硬件實(shí)施例、完全軟件實(shí)施例、或結(jié)合軟件和硬件方面的實(shí)施例的形式。而且，本申請(qǐng)可采用在一個(gè)或多個(gè)其中包含有計(jì)算機(jī)可用程序代碼的計(jì)算機(jī)可用存儲(chǔ)介質(zhì)(包括但不限于磁盤(pán)存儲(chǔ)器、CD-ROM、光學(xué)存儲(chǔ)器等)上實(shí)施的計(jì)算機(jī)程序產(chǎn)品的形式。

本申請(qǐng)是參照根據(jù)本申請(qǐng)實(shí)施例的方法、設(shè)備(系統(tǒng))、和計(jì)算機(jī)程序產(chǎn)品的流程圖和/或方框圖來(lái)描述的。應(yīng)理解可由計(jì)算機(jī)程序指令實(shí)現(xiàn)流程圖和/或方框圖中的每一流程和/或方框、以及流程圖和/或方框圖中的流程和/或方框的結(jié)合?？商峁┻@些計(jì)算機(jī)程序指令到通用計(jì)算機(jī)、專用計(jì)算機(jī)、嵌入式處理機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器以產(chǎn)生一個(gè)機(jī)器，使得通過(guò)計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備的處理器執(zhí)行的指令產(chǎn)生用于實(shí)現(xiàn)在流程圖一個(gè)流程或多個(gè)流程和/或方框圖一個(gè)方框或多個(gè)方框中指定的功能的裝置。

這些計(jì)算機(jī)程序指令也可存儲(chǔ)在能引導(dǎo)計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備以特定方式工作的計(jì)算機(jī)可讀存儲(chǔ)器中，使得存儲(chǔ)在該計(jì)算機(jī)可讀存儲(chǔ)器中的指令產(chǎn)生包括指令裝置的制造品，該指令裝置實(shí)現(xiàn)在流程圖一個(gè)流程或多個(gè)流程和/或方框圖一個(gè)方框或多個(gè)方框中指定的功能。

這些計(jì)算機(jī)程序指令也可裝載到計(jì)算機(jī)或其他可編程數(shù)據(jù)處理設(shè)備上，使得在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行一系列操作步驟以產(chǎn)生計(jì)算機(jī)實(shí)現(xiàn)的處理，從而在計(jì)算機(jī)或其他可編程設(shè)備上執(zhí)行的指令提供用于實(shí)現(xiàn)在流程圖一個(gè)流程或多個(gè)流程和/或方框圖一個(gè)方框或多個(gè)方框中指定的功能的步驟。

盡管已描述了本申請(qǐng)的優(yōu)選實(shí)施例，但本領(lǐng)域內(nèi)的技術(shù)人員一旦得知了基本創(chuàng)造性概念，則可對(duì)這些實(shí)施例作出另外的變更和修改。所以，所附權(quán)利要求意欲解釋為包括優(yōu)選實(shí)施例以及落入本申請(qǐng)范圍的所有變更和修改。