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

背景技術(shù)：

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

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

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

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

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

本申請實施例提供了一種升級方法，包括：

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

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

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

本申請實施例提供了一種升級裝置，包括：

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

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

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

有益效果如下：

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

附圖說明

下面將參照附圖描述本申請的具體實施例，其中：

圖1示出了本申請實施例中一種升級方法實施的流程示意圖；

圖2示出了本申請實施例中又一種升級方法實施的流程示意圖；

圖3示出了本申請實施例中又一種升級方法實施的流程示意圖；

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

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

具體實施方式

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

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

基于此，本申請實施例提出了一種升級方法及裝置，下面進行說明。

圖1示出了本申請實施例提供的一種升級方法，如圖1所示，包括：

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

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

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

本實施例中待變更包包括但不限于SNAPSHOT包，對此本實施例中不做具體限定。

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

通過Maven插件獲取當前Maven工程的pom(項目對象模型)文件；

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

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

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

獲取所述待變更包的映射規(guī)則，所述映射規(guī)則包括：如果所述待變更包中包括預設后綴名，則將所述待變更的包的版本號的后綴名對應修改為升級包的后綴名，如果所述待變更包中不包括所述預設后綴名，則在所述待變更包后添加所述升級包的后綴名；

根據(jù)所述待變更包的映射規(guī)則，確認與所述待變更包對應的升級包的后綴名。

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

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

解析出所述jar對應的pom文件的屬性列表，并將所述當前Maven工程的內(nèi)置變量添加到所述屬性列表中，所述當前Maven工程的內(nèi)置變量包括：組織標識、項目標識和版本號；

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

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

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

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

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

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

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

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

獲取所述第二依賴鏈路中對應所述第一依賴鏈路中修改的jar，計算所述第二鏈路中對應所述第一依賴鏈路中修改后的jar的第二MD5值；

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

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

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

步驟201、獲取當前Maven工程的第一依賴鏈路。

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

步驟1)通過Maven插件獲取當前Maven工程的pom文件；

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

步驟3)通過Maven插件對該第1節(jié)點進行解析，獲得所述第1節(jié)點的解 析結(jié)果；

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

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

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

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é)點，其中包含SNAPSHOT的包是待變更包。在具體解析的過程中，通過Maven插件獲取當前工程的pom文件，從該文件中解析出第1個節(jié)點com.tmall：sak-app：war：1.0-SNAPSHOT，然后對該節(jié)點進行解析，對解析結(jié)果進行分析，確認是否有該節(jié)點的依賴節(jié)點，如解析出該節(jié)點的依賴節(jié)點為com.tmall：sak-biz-common：jar：1.0-SNAPSHOT，則繼續(xù)對該節(jié)點進行解析，直 到解析到com.taobao.sharereport：share-report-common：jar：1.5.1-SNAPSHOT節(jié)點，發(fā)現(xiàn)其沒有后續(xù)依賴節(jié)點，則完成依賴鏈路的解析，得到如上的依賴節(jié)點。

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

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

具體應用中，會對于不同的待變更包可以預先設定多個映射規(guī)則，包括：如果所述待變更包中包括預設后綴名，則將所述待變更的包的版本號的后綴名對應修改為升級包的后綴名，如果所述待變更包中不包括所述預設后綴名，則在所述待變更包后添加所述升級包的后綴名。例如，每個工程的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。對于其他類型的待變更包也可以設置其他對應的映射規(guī)則，其中映射規(guī)則可以存儲在Maven倉庫中，也可以單獨創(chuàng)建文件家存儲，對此本實施例中不做具體限定。

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

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

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

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

本實施例中，如果存在多條依賴鏈路，則遍歷依賴鏈路中的每個jar的pom文件，獲取當前jar對應的pom的所有父pom列表，其中父pom列表的形式為GroupId：artifactId：version。確認父pom列表中是否有待變更包，如SNAPSHOT包，如果有，則確認該父pom列表需要修改，如果沒有待變更包，則不需要修改。

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

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

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

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

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

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

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

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

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

如步驟201中示范的鏈路，升級后轉(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。

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

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

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

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

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

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

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

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

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

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

確認父pom列表中是否有待變更包，如SNAPSHOT包，如果有，則確認該父pom列表需要修改，如果沒有待變更包，則不需要修改。

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

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

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

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

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

本實施例中，對于不包含待變更包的節(jié)點不需進行修改，所以在進行驗證時，只需對第一依賴鏈路中修改的jar進行驗證，如依賴鏈路為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個包，F(xiàn)，G因為后面沒有依賴任何的 SNAPSHOT版本，所以不需要對F，G進行驗證，只需驗證A，B，C，D，E的MD5值在第一鏈路中和第二鏈路中是否相同。

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

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

步驟308、將第二依賴鏈路存儲到Maven倉庫中。

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

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

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

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

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

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

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

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

第一獲取單元401a，用于通過Maven插件獲取當前Maven工程的項目對象模型pom文件；

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

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

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

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

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

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

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

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

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

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

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

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

參見圖5，在另一種可能的實施方式中，所述裝置還包括：

驗證模塊404，用于驗證所述第二依賴鏈路的消息摘要算法第五版MD5值與所述第一鏈路的MD5值是否相同，如果是，則將所述第二依賴鏈路存儲到Maven倉庫中。

參見圖5，在另一種可能的實施方式中，所述驗證模塊404包括：

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

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

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

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

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

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

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

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

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

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