软件更新方法、装置、电子设备及存储介质与流程

文档序号:31538651发布日期:2022-09-16 23:15阅读:96来源:国知局
软件更新方法、装置、电子设备及存储介质与流程

1.本发明涉及应用软件系统开发技术领域,具体涉及一种软件更新方法、装置、电子设备及存储介质。


背景技术:

2.软件更新是软件研发上线的重要环节,在软件进行安全加固、基础模块版本变更、增加新的需求变更,及软件需要漏洞修复等情况下,需要对软件进行升级或者降级,现有技术通常是基于新版本搭建开发框架,将基于旧框架开发的业务代码手动复制到新开发框架中,并修改需要更新的文件及手动执行数据库脚本,最终完成框架升级更新工作。
3.然而,现有技术在修改需要更新的文件及手动执行数据库脚本时,未对更新后的文件进行间接依赖缺失及依赖冲突检查,无法判断更新内容与原软件是否存在冲突或缺失,导致软件更新效率及准确率低。
4.因此,有必要提出一种可以快速准确的进行软件更新的方法。


技术实现要素:

5.鉴于以上内容,有必要提出一种软件更新方法、装置、电子设备及存储介质,通过对第三项目文件进行间接依赖缺失检查和依赖冲突检查,提高了软件更新的效率及准确率。
6.本发明的第一方面提供一种软件更新方法,所述方法包括:
7.响应于接收的软件更新指令,获取待更新软件的配置文件;
8.对所述待更新软件的配置文件进行解析,获取多个第一项目文件;
9.从所述待更新软件的原始代码中提取出多个第二项目文件;
10.当每个第一项目文件存在于所述多个第二项目文件中,基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件;
11.对所述第三项目文件进行间接依赖缺失检查,得到检查结果;
12.基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件;
13.基于所述第四项目文件执行所述待更新软件的更新。
14.可选地,所述基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件包括:
15.对所述每个第一项目文件进行解析,得到所述每个第一项目文件的第一软件包集合和配置项;
16.识别所述配置项的类别;
17.当所述配置项的类别为第一类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文
件对应的第三项目文件;
18.当所述配置项的类别为第二类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,并从所述第二项目文件中删除所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件;
19.当所述配置项的类别为第三类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的运行环境更新所述第二软件包集合中的运行环境参数,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件。
20.可选地,所述基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合包括:
21.判断所述第一软件包集合中的每个第一软件包是否存在于第二软件包集合中;
22.当所述第一软件包集合中的每个第一软件包存在于第二软件包集合中,获取每个第一软件包对应的第二软件包,并基于所述配置项中的更新数据更新所述每个第一软件包对应的第二软件包,得到第三软件包集合;
23.当所述第一软件包集合中的任意一个第一软件包不存在于第二软件包集合中,将所述任意一个第一软件包添加至所述第二软件包集合中,得到第三软件包集合。
24.可选地,所述对所述第三项目文件进行间接依赖缺失检查,得到检查结果包括:
25.通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
26.将所述第三软件包集合与所述第四软件包集合进行对比;
27.当所述第三软件包集合与所述第四软件包集合一致时,确定检查结果为所述第三项目文件不存在缺失;
28.当所述第三软件包集合与所述第四软件包集合不一致时,确定检查结果为所述第三项目文件存在缺失。
29.可选地,所述方法还包括:
30.当确定所述检查结果为所述第三项目文件存在缺失时,获取缺失的目标软件包,并将所述目标软件包添加至所述第四软件包集合中,得到第五软件包集合,并重复执行对所述第五软件包集合进行二次间接依赖缺失检查,直至确定检查结果为所述第三项目文件不存在缺失。
31.可选地,所述基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件包括:
32.当检查结果为所述第三项目文件不存在缺失时,通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
33.将所述第四软件包集合中的每个第四软件包的第一版本号与所述第三软件包集合中的对应第三软件包的第二版本号进行对比;
34.当每个第四软件包的第一版本号与对应第三软件包的第二版本号一致时,确定所述第三项目文件不存在依赖冲突,将所述第四软件包集合确定为第四项目文件。
35.可选地,所述基于所述第四项目文件执行所述待更新软件的更新包括:
36.对所述第四项目文件执行更新指令;
37.检查所述第四项目文件中的每个第四软件是否编译通过;
38.当所述第四项目文件中的每个第四软件编译通过时,确定执行所述待更新软件的更新;
39.当所述第四项目文件中的任意一个第四软件编译不通过时,确定不执行所述待更新软件的更新。
40.本发明的第二方面提供一种软件更新装置,所述装置包括:
41.获取模块,用于响应于接收的软件更新指令,获取待更新软件的配置文件;
42.解析模块,用于对所述待更新软件的配置文件进行解析,获取多个第一项目文件;
43.提取模块,用于从所述待更新软件的原始代码中提取出多个第二项目文件;
44.第一更新模块,用于当每个第一项目文件存在于所述多个第二项目文件中,基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件;
45.第一检查模块,用于对所述第三项目文件进行间接依赖缺失检查,得到检查结果;
46.第二检查模块,用于基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件;
47.第二更新模块,用于基于所述第四项目文件执行所述待更新软件的更新。
48.本发明的第三方面提供一种电子设备,所述电子设备包括处理器和存储器,所述处理器用于执行所述存储器中存储的计算机程序时实现所述的软件更新方法。
49.本发明的第四方面提供一种计算机可读存储介质,所述计算机可读存储介质上存储有计算机程序,所述计算机程序被处理器执行时实现所述的软件更新方法。
50.综上所述,本发明所述的软件更新方法、装置、电子设备及存储介质,能够推动智慧城市的建设,应用于智慧建筑、智慧安防、智慧社区、智慧生活、物联网等领域,通过对所述待更新软件的配置文件进行解析,获取多个第一项目文件,依次检查每个第一项目文件是否存在于从所述待更新软件的原始代码中提取出的多个第二项目文件,通过依次检查每个第一项目文件是否存在于所述多个第二项目文件中,初步评估更新内容与原软件存在冲突,结束待更新软件的更新,提高了待更新软件的更新效率及准确率。基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件,对所述第三项目文件进行间接依赖缺失检查,基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件,解决了现有的软件更新过程中由于存在软件包缺失或者依赖冲突导致的更新后的软件无法运行的情况,提高了软件的更新效率及准确率。
附图说明
51.图1是本发明实施例一提供的软件更新方法的流程图。
52.图2是本发明实施例二提供的软件更新装置的结构图。
53.图3是本发明实施例三提供的电子设备的结构示意图。
具体实施方式
54.为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施例对本发明进行详细描述。需要说明的是,在不冲突的情况下,本发明的实施例及实施例中的特征可以相互组合。
55.除非另有定义,本文所使用的所有的技术和科学术语与属于本发明的技术领域的技术人员通常理解的含义相同。本文中在本发明的说明书中所使用的术语只是为了描述具体的实施例的目的,不是旨在于限制本发明。
56.实施例一
57.图1是本发明实施例一提供的软件更新方法的流程图。
58.在本实施例中,所述软件更新方法可以应用于电子设备中,对于需要进行软件更新的电子设备,可以直接在电子设备上集成本发明的方法所提供的软件更新的功能,或者以软件开发工具包(software development kit,sdk)的形式运行在电子设备中。
59.如图1所示,所述软件更新方法具体包括以下步骤,根据不同的需求,该流程图中步骤的顺序可以改变,某些可以省略。
60.100,响应于接收的软件更新指令,获取待更新软件的配置文件。
61.本实施例中,软件更新包括软件升级或者软件降级,软件更新既要保证原系统功能正常,又需要判断评估更新内容与原软件是否存在冲突或缺失,查找并消除处理,确保更新软件稳定上线。
62.本实施例中,采用maven项目管理工具实现软件更新,所述软件更新指令用以请求对待更新软件进行更新的指令,所述待更新软件的配置文件中包含有配置项,及所述配置项中的更新数据。
63.101,对所述待更新软件的配置文件进行解析,获取多个第一项目文件。
64.本实施例中,所述第一项目文件是指项目的pom文件,pom文件通常存在继承关系,将其中的一个pom文件作为根节点,与所述pom文件存在继承关系的其余pom以树型结构的形式存在,每个子pom文件可继承父pom文件已引入的依赖关系。
65.在一个可选的实施例中,所述对所述待更新软件的配置文件进行解析,获取多个第一项目文件包括:
66.采用预设的解析工具对所述待更新软件的配置文件进行解析,得到项目树;
67.遍历所述项目树,获取多个第一项目文件,其中,每个第一项目文件中包含有配置项。
68.具体地,所述配置项可以为以下一种或者多种组合:第一类配置项;第二类配置项;第三类配置项,其中,所述第一类配置项为新增或者更新软件包;第二类配置项为删除软件包;第三类配置项为更新待更新软件的运行环境。
69.本实施例中,预设的解析工具可以为xmlutil工具,采用所述xmlutil工具可以解析出所述待更新软件的配置文件中的所有maven依赖关系,构建项目树,遍历所述项目树获取所述项目树中的所有第一项目文件,避免出现遗漏第一项目文件的情况,提高了获取的第一项目文件的完整性。
70.102,从所述待更新软件的原始代码中提取出多个第二项目文件。
71.本实施例中,第二项目文件是指项目的pom文件,一个软件通常由多个模块做成,
在使用maven构建软件代码时,每个模块的代码结构中包含有一个pom.xml文件,maven把pom文件作为软件项目对象模型,pom文件主要包含:软件配置数据,开发者信息描述,软件依赖jar定义、编译参数以及其它软件代码相关内容,在一个软件由多个模块组成,即软件的原始代码中包含多个pom文件,故从所述待更新软件的原始代码中提取出多个第二项目文件,便于后续与解析待更新软件的配置文件后得到的多个第一项目文件进行对比,根据对比结果评估所述待更新软件是否执行更新操作。
72.在一个可选的实施例中,在所述从所述待更新软件的原始代码中提取出多个第二项目文件之后,所述方法还包括:
73.依次检查每个第一项目文件是否存在于所述多个第二项目文件中。
74.本实施例中,由于待更新软件的配置项包含有新增或者更新jar包、删除jar包及更新待更新软件的运行环境,需要检查待更新软件的配置文件中的第一项目文件是否存在与原始代码文件中的第二项目文件中,当每个第一项目文件存在于多个第二项目文件中,根据对应的配置项更新对应的第二项目文件;当每个第一项目文件不存在于多个第二项目文件中,创建评估报告并结束软件更新操作。
75.进一步地,所述依次检查每个第一项目文件是否存在于所述多个第二项目文件中包括:
76.分别对所述多个第一项目文件及所述多个第二项目文件进行解析,获取每个第一项目文件的第一编码及每个第二项目文件的第二编码;
77.将每个第一项目文件的第一编码与多个第二项目文件的多个第二编码进行匹配;
78.当所述第一编码与所述多个第二编码中的任意一个编码完全匹配时,确定对应的第一项目文件存在于所述多个第二项目文件中;
79.当所述第一编码与所述多个第二编码中的每个第二编码不完全匹配时,确定对应的第一项目文件不存在于所述多个第二项目文件中。
80.本实施例中,第一编码用以唯一识别每个第一项目文件,第二编码用以唯一识别每个第二项目文件。
81.本实施例中,可以采用所述预设的解析工具分别对所述多个第一项目文件及所述多个第二项目文件进行解析。
82.本实施例中,通过依次检查每个第一项目文件是否存在于所述多个第二项目文件中,初步评估更新内容与原软件存在冲突,结束待更新软件的更新,提高了待更新软件的更新效率及准确率。
83.103,当每个第一项目文件存在于所述多个第二项目文件中,基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件。
84.本实施例中,所述第三项目文件是指基于待更新软件的配置文件更新后的项目文件。
85.在一个可选的实施例中,所述基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件包括:
86.对所述每个第一项目文件进行解析,得到所述每个第一项目文件的第一软件包集合和配置项;
87.识别所述配置项的类别;
88.当所述配置项的类别为第一类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件;
89.当所述配置项的类别为第二类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,并从所述第二项目文件中删除所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件;
90.当所述配置项的类别为第三类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的运行环境更新所述第二软件包集合中的运行环境参数,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件。
91.本实施例中,所述运行环境参数可以为java版本号。
92.进一步地,所述基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合包括:
93.判断所述第一软件包集合中的每个第一软件包是否存在于第二软件包集合中;
94.当所述第一软件包集合中的每个第一软件包存在于第二软件包集合中,获取每个第一软件包对应的第二软件包,并基于所述配置项中的更新数据更新所述每个第一软件包对应的第二软件包,得到第三软件包集合;
95.当所述第一软件包集合中的任意一个第一软件包不存在于第二软件包集合中,将所述任意一个第一软件包添加至所述第二软件包集合中,得到第三软件包集合。
96.本实施例中,可以采用xmlutil工具对所述每个第一项目文件进行解析,根据解析结果进行待更新软件的更新,得到第三项目文件,在更新过程中,通过识别所述配置项的类别,基于不同的配置项采用不同的更新方式进行更新,更加的具有针对性,提高了待更新软件的更新效率。
97.104,对所述第三项目文件进行间接依赖缺失检查,得到检查结果。
98.本实施例中,java软件的软件包之间的依赖分为直接依赖和间接依赖,直接依赖是指在软件配置中明确以定义完成软件代码编译的jar包,间接依赖是指直接依赖包又依赖的其它软件包,它们的作用及依赖过程通常发生在软件运行过程中。
99.本实施例中,第三项目文件中的软件包集合之间存在依赖关系,在进行软件更新时,可能存在软件包缺失的现象,若直接采用第三项目文件进行待更新软件的更新,更新后的软件可能存在无法运行的情况,导致待更新软件的更新效率及准确率低下。
100.在一个可选的实施例中,所述对所述第三项目文件进行间接依赖缺失检查,得到检查结果包括:
101.通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
102.将所述第三软件包集合与所述第四软件包集合进行对比;
103.当所述第三软件包集合与所述第四软件包集合一致时,确定检查结果为所述第三
项目文件不存在缺失;
104.当所述第三软件包集合与所述第四软件包集合不一致时,确定检查结果为所述第三项目文件存在缺失。
105.进一步地,所述方法还包括:
106.当确定所述检查结果为所述第三项目文件存在缺失时,获取缺失的目标软件包,并将所述目标软件包添加至所述第四软件包集合中,得到第五软件包集合,并重复执行对所述第五软件包集合进行二次间接依赖缺失检查,直至确定检查结果为所述第三项目文件不存在缺失。
107.本实施例中,通过对所述第三项目文件进行间接依赖缺失检查,解决了现有的软件更新过程中由于存在软件包缺失导致的更新后的软件无法运行的情况,提高了软件的更新效率及准确率。
108.105,基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件。
109.本实施例中,所述依赖冲突检查是指检查运行后的第三项目文件依赖的第四软件包集合中的软件包的版本号是否与更新后的第三项目文件中包含的第三软件包集合中的对应软件包的版本号是否一致,确保更新过程中不会出现依赖冲突的现象,提高了软件更新的准确率和效率。
110.在一个可选的实施例中,所述基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件包括:
111.当检查结果为所述第三项目文件不存在缺失时,通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
112.将所述第四软件包集合中的每个第四软件包的第一版本号与所述第三软件包集合中的对应第三软件包的第二版本号进行对比;
113.当每个第四软件包的第一版本号与对应第三软件包的第二版本号一致时,确定所述第三项目文件不存在依赖冲突,将所述第四软件包集合确定为第四项目文件。
114.进一步地,所述将所述第四软件包集合中的每个第四软件包的第一版本号与所述第三软件包集合中的对应第三软件包的第二版本号进行对比包括:
115.当每个第四软件包的第一版本号与对应第三软件包的第二版本号不一致时,将每个第四软件包的第一版本号与对应第三软件包的第二版本号进行比较;
116.当每个第四软件包的第一版本号大于或者等于对应第三软件包的第二版本号时,确定所述第三项目文件不存在依赖冲突,将所述第四软件包集合确定为第四项目文件;
117.当每个第四软件包的第一版本号小于对应第三软件包的第二版本号时,将所述第四软件包的第一版本号更新为第二版本号,对更新后的第四软件包集合重复执行对所述第三项目文件进行二次依赖冲突检查,直至所述第三项目文件不存在依赖冲突,将所述更新后的第四软件包集合确定为第四项目文件。
118.本实施例中,第一版本号是指解析第三项目文件后的第四软件包的版本号;第二版本号是指第三项目文件中包含的第三软件包的版本号。
119.106,基于所述第四项目文件执行所述待更新软件的更新。
120.本实施例中,在基于所述第四项目文件执行所述待更新软件的更新过程中,通过maven-model提供的invocationrequest接口,输入第四项目文件路径信息并执行更新(compile)命令,检查所述第四项目文件所在模块代码是否编译通过,若编译通过,确定所述待更新软件可以更新;若编译不通过,确定所述待更新软件若更新,可能会出现更新下失败的问题,创建可更新报告,并结束本次评估操作。
121.在一个可选的实施例中,所述基于所述第四项目文件执行所述待更新软件的更新包括:
122.对所述第四项目文件执行更新指令;
123.检查所述第四项目文件中的每个第四软件是否编译通过;
124.当所述第四项目文件中的每个第四软件编译通过时,确定执行所述待更新软件的更新;
125.当所述第四项目文件中的任意一个第四软件编译不通过时,确定不执行所述待更新软件的更新。
126.本实施例中,在引入的新软件包是,需要检查新的软件包是否可用,及变更后的软件代码是否可正常编译等,若编译通过,确定更新后的软件包可使用;若编译不通过,确定更新后的软件包可能不能运行。
127.进一步地,在所述确定不执行所述待更新软件的更新之后,所述方法还包括:
128.创建所述待更新软件的更新报告。
129.本实施例中,在确定不执行所述待更新软件的更新之后,创建所述待更新软件的可更新评估报告,便于后续基于所述可更新评估报告确定是否更新所述待更新软件及如何更新所述待更新软件,提高了软件更新的维护效率。
130.综上所述,本实施例所述的软件更新方法,通过对所述待更新软件的配置文件进行解析,获取多个第一项目文件,依次检查每个第一项目文件是否存在于从所述待更新软件的原始代码中提取出的多个第二项目文件,通过依次检查每个第一项目文件是否存在于所述多个第二项目文件中,初步评估更新内容与原软件存在冲突,结束待更新软件的更新,提高了待更新软件的更新效率及准确率。基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件,对所述第三项目文件进行间接依赖缺失检查,基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件,解决了现有的软件更新过程中由于存在软件包缺失或者依赖冲突导致的更新后的软件无法运行的情况,提高了软件的更新效率及准确率。
131.实施例二
132.图2是本发明实施例二提供的软件更新装置的结构图。
133.在一些实施例中,所述软件更新装置20可以包括多个由程序代码段所组成的功能模块。所述软件更新装置20中的各个程序段的程序代码可以存储于电子设备的存储器中,并由所述至少一个处理器所执行,以执行(详见图1描述)软件更新的功能。
134.本实施例中,所述软件更新装置20根据其所执行的功能,可以被划分为多个功能模块。所述功能模块可以包括:获取模块201、解析模块202、提取模块203、第一更新模块204、第一检查模块205、第二检查模块206及第二更新模块207。本发明所称的模块是指一种能够被至少一个处理器所执行并且能够完成固定功能的一系列计算机可读指令段,其存储
在存储器中。在本实施例中,关于各模块的功能将在后续的实施例中详述。
135.获取模块201,用于响应于接收的软件更新指令,获取待更新软件的配置文件。
136.本实施例中,软件更新包括软件升级或者软件降级,软件更新既要保证原系统功能正常,又需要判断评估更新内容与原软件是否存在冲突或缺失,查找并消除处理,确保更新软件稳定上线。
137.本实施例中,采用maven项目管理工具实现软件更新,所述软件更新指令用以请求对待更新软件进行更新的指令,所述待更新软件的配置文件中包含有配置项,及所述配置项中的更新数据。
138.解析模块202,用于对所述待更新软件的配置文件进行解析,获取多个第一项目文件。
139.本实施例中,所述第一项目文件是指项目的pom文件,pom文件通常存在继承关系,将其中的一个pom文件作为根节点,与所述pom文件存在继承关系的其余pom以树型结构的形式存在,每个子pom文件可继承父pom文件已引入的依赖关系。
140.在一个可选的实施例中,所述解析模块202对所述待更新软件的配置文件进行解析,获取多个第一项目文件包括:
141.采用预设的解析工具对所述待更新软件的配置文件进行解析,得到项目树;
142.遍历所述项目树,获取多个第一项目文件,其中,每个第一项目文件中包含有配置项。
143.具体地,所述配置项可以为以下一种或者多种组合:第一类配置项;第二类配置项;第三类配置项,其中,所述第一类配置项为新增或者更新软件包;第二类配置项为删除软件包;第三类配置项为更新待更新软件的运行环境。
144.本实施例中,预设的解析工具可以为xmlutil工具,采用所述xmlutil工具可以解析出所述待更新软件的配置文件中的所有maven依赖关系,构建项目树,遍历所述项目树获取所述项目树中的所有第一项目文件,避免出现遗漏第一项目文件的情况,提高了获取的第一项目文件的完整性。
145.提取模块203,用于从所述待更新软件的原始代码中提取出多个第二项目文件。
146.本实施例中,第二项目文件是指项目的pom文件,一个软件通常由多个模块做成,在使用maven构建软件代码时,每个模块的代码结构中包含有一个pom.xml文件,maven把pom文件作为软件项目对象模型,pom文件主要包含:软件配置数据,开发者信息描述,软件依赖jar定义、编译参数以及其它软件代码相关内容,在一个软件由多个模块组成,即软件的原始代码中包含多个pom文件,故从所述待更新软件的原始代码中提取出多个第二项目文件,便于后续与解析待更新软件的配置文件后得到的多个第一项目文件进行对比,根据对比结果评估所述待更新软件是否执行更新操作。
147.在一个可选的实施例中,在所述从所述待更新软件的原始代码中提取出多个第二项目文件之后,依次检查每个第一项目文件是否存在于所述多个第二项目文件中。
148.本实施例中,由于待更新软件的配置项包含有新增或者更新jar包、删除jar包及更新待更新软件的运行环境,需要检查待更新软件的配置文件中的第一项目文件是否存在与原始代码文件中的第二项目文件中,当每个第一项目文件存在于多个第二项目文件中,根据对应的配置项更新对应的第二项目文件;当每个第一项目文件不存在于多个第二项目
文件中,创建评估报告并结束软件更新操作。
149.进一步地,所述依次检查每个第一项目文件是否存在于所述多个第二项目文件中包括:
150.分别对所述多个第一项目文件及所述多个第二项目文件进行解析,获取每个第一项目文件的第一编码及每个第二项目文件的第二编码;
151.将每个第一项目文件的第一编码与多个第二项目文件的多个第二编码进行匹配;
152.当所述第一编码与所述多个第二编码中的任意一个编码完全匹配时,确定对应的第一项目文件存在于所述多个第二项目文件中;
153.当所述第一编码与所述多个第二编码中的每个第二编码不完全匹配时,确定对应的第一项目文件不存在于所述多个第二项目文件中。
154.本实施例中,第一编码用以唯一识别每个第一项目文件,第二编码用以唯一识别每个第二项目文件。
155.本实施例中,可以采用所述预设的解析工具分别对所述多个第一项目文件及所述多个第二项目文件进行解析。
156.本实施例中,通过依次检查每个第一项目文件是否存在于所述多个第二项目文件中,初步评估更新内容与原软件存在冲突,结束待更新软件的更新,提高了待更新软件的更新效率及准确率。
157.第一更新模块204,用于当每个第一项目文件存在于所述多个第二项目文件中,基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件。
158.本实施例中,所述第三项目文件是指基于待更新软件的配置文件更新后的项目文件。
159.在一个可选的实施例中,所述第一更新模块204基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件包括:
160.对所述每个第一项目文件进行解析,得到所述每个第一项目文件的第一软件包集合和配置项;
161.识别所述配置项的类别;
162.当所述配置项的类别为第一类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件;
163.当所述配置项的类别为第二类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,并从所述第二项目文件中删除所述第二软件包集合,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件;
164.当所述配置项的类别为第三类配置项时,从所述第一项目文件对应的第二项目文件中读取所述配置项对应的第二软件包集合,基于所述配置项中的运行环境更新所述第二软件包集合中的运行环境参数,得到第三软件包集合,并将所述第三软件包集合确定为所述每个第二项目文件对应的第三项目文件。
165.本实施例中,所述运行环境参数可以为java版本号。
166.进一步地,所述基于所述配置项中的更新数据更新所述第二软件包集合,得到第三软件包集合包括:
167.判断所述第一软件包集合中的每个第一软件包是否存在于第二软件包集合中;
168.当所述第一软件包集合中的每个第一软件包存在于第二软件包集合中,获取每个第一软件包对应的第二软件包,并基于所述配置项中的更新数据更新所述每个第一软件包对应的第二软件包,得到第三软件包集合;
169.当所述第一软件包集合中的任意一个第一软件包不存在于第二软件包集合中,将所述任意一个第一软件包添加至所述第二软件包集合中,得到第三软件包集合。
170.本实施例中,可以采用xmlutil工具对所述每个第一项目文件进行解析,根据解析结果进行待更新软件的更新,得到第三项目文件,在更新过程中,通过识别所述配置项的类别,基于不同的配置项采用不同的更新方式进行更新,更加的具有针对性,提高了待更新软件的更新效率。
171.第一检查模块205,用于对所述第三项目文件进行间接依赖缺失检查,得到检查结果。
172.本实施例中,java软件的软件包之间的依赖分为直接依赖和间接依赖,直接依赖是指在软件配置中明确以定义完成软件代码编译的jar包,间接依赖是指直接依赖包又依赖的其它软件包,它们的作用及依赖过程通常发生在软件运行过程中。
173.本实施例中,第三项目文件中的软件包集合之间存在依赖关系,在进行软件更新时,可能存在软件包缺失的现象,若直接采用第三项目文件进行待更新软件的更新,更新后的软件可能存在无法运行的情况,导致待更新软件的更新效率及准确率低下。
174.在一个可选的实施例中,所述第一检查模块205对所述第三项目文件进行间接依赖缺失检查,得到检查结果包括:
175.通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
176.将所述第三软件包集合与所述第四软件包集合进行对比;
177.当所述第三软件包集合与所述第四软件包集合一致时,确定检查结果为所述第三项目文件不存在缺失;
178.当所述第三软件包集合与所述第四软件包集合不一致时,确定检查结果为所述第三项目文件存在缺失。
179.进一步地,当确定所述检查结果为所述第三项目文件存在缺失时,获取缺失的目标软件包,并将所述目标软件包添加至所述第四软件包集合中,得到第五软件包集合,并重复执行对所述第五软件包集合进行二次间接依赖缺失检查,直至确定检查结果为所述第三项目文件不存在缺失。
180.本实施例中,通过对所述第三项目文件进行间接依赖缺失检查,解决了现有的软件更新过程中由于存在软件包缺失导致的更新后的软件无法运行的情况,提高了软件的更新效率及准确率。
181.第二检查模块206,用于基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件。
182.本实施例中,所述依赖冲突检查是指检查运行后的第三项目文件依赖的第四软件包集合中的软件包的版本号是否与更新后的第三项目文件中包含的第三软件包集合中的对应软件包的版本号是否一致,确保更新过程中不会出现依赖冲突的现象,提高了软件更新的准确率和效率。
183.在一个可选的实施例中,所述第二检查模块206基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件包括:
184.当检查结果为所述第三项目文件不存在缺失时,通过预设的接口输入所述第三项目文件的路径信息,并查看所述第三项目文件的软件包依赖树,遍历所述软件包依赖树获取所述第三项目文件依赖的第四软件包集合;
185.将所述第四软件包集合中的每个第四软件包的第一版本号与所述第三软件包集合中的对应第三软件包的第二版本号进行对比;
186.当每个第四软件包的第一版本号与对应第三软件包的第二版本号一致时,确定所述第三项目文件不存在依赖冲突,将所述第四软件包集合确定为第四项目文件。
187.进一步地,所述将所述第四软件包集合中的每个第四软件包的第一版本号与所述第三软件包集合中的对应第三软件包的第二版本号进行对比包括:
188.当每个第四软件包的第一版本号与对应第三软件包的第二版本号不一致时,将每个第四软件包的第一版本号与对应第三软件包的第二版本号进行比较;
189.当每个第四软件包的第一版本号大于或者等于对应第三软件包的第二版本号时,确定所述第三项目文件不存在依赖冲突,将所述第四软件包集合确定为第四项目文件;
190.当每个第四软件包的第一版本号小于对应第三软件包的第二版本号时,将所述第四软件包的第一版本号更新为第二版本号,对更新后的第四软件包集合重复执行对所述第三项目文件进行二次依赖冲突检查,直至所述第三项目文件不存在依赖冲突,将所述更新后的第四软件包集合确定为第四项目文件。
191.本实施例中,第一版本号是指解析第三项目文件后的第四软件包的版本号;第二版本号是指第三项目文件中包含的第三软件包的版本号。
192.第二更新模块207,用于基于所述第四项目文件执行所述待更新软件的更新。
193.本实施例中,在基于所述第四项目文件执行所述待更新软件的更新过程中,通过maven-model提供的invocationrequest接口,输入第四项目文件路径信息并执行更新(compile)命令,检查所述第四项目文件所在模块代码是否编译通过,若编译通过,确定所述待更新软件可以更新;若编译不通过,确定所述待更新软件若更新,可能会出现更新下失败的问题,创建可更新报告,并结束本次评估操作。
194.在一个可选的实施例中,所述第二更新模块207基于所述第四项目文件执行所述待更新软件的更新包括:
195.对所述第四项目文件执行更新指令;
196.检查所述第四项目文件中的每个第四软件是否编译通过;
197.当所述第四项目文件中的每个第四软件编译通过时,确定执行所述待更新软件的更新;
198.当所述第四项目文件中的任意一个第四软件编译不通过时,确定不执行所述待更新软件的更新。
199.本实施例中,在引入的新软件包是,需要检查新的软件包是否可用,及变更后的软件代码是否可正常编译等,若编译通过,确定更新后的软件包可使用;若编译不通过,确定更新后的软件包可能不能运行。
200.进一步地,在所述确定不执行所述待更新软件的更新之后,创建所述待更新软件的更新报告。
201.本实施例中,在确定不执行所述待更新软件的更新之后,创建所述待更新软件的可更新评估报告,便于后续基于所述可更新评估报告确定是否更新所述待更新软件及如何更新所述待更新软件,提高了软件更新的维护效率。
202.综上所述,本实施例所述的软件更新装置,通过对所述待更新软件的配置文件进行解析,获取多个第一项目文件,依次检查每个第一项目文件是否存在于从所述待更新软件的原始代码中提取出的多个第二项目文件,通过依次检查每个第一项目文件是否存在于所述多个第二项目文件中,初步评估更新内容与原软件存在冲突,结束待更新软件的更新,提高了待更新软件的更新效率及准确率。基于所述每个第一项目文件中的配置项更新对应的第二项目文件,得到所述每个第二项目文件对应的第三项目文件,对所述第三项目文件进行间接依赖缺失检查,基于所述检查结果对所述第三项目文件进行依赖冲突检查,获取第四项目文件,解决了现有的软件更新过程中由于存在软件包缺失或者依赖冲突导致的更新后的软件无法运行的情况,提高了软件的更新效率及准确率。
203.实施例三
204.参阅图3所示,为本发明实施例三提供的电子设备的结构示意图。在本发明较佳实施例中,所述电子设备3包括存储器31、至少一个处理器32、至少一条通信总线33及收发器34。
205.本领域技术人员应该了解,图3示出的电子设备的结构并不构成本发明实施例的限定,既可以是总线型结构,也可以是星形结构,所述电子设备3还可以包括比图示更多或更少的其他硬件或者软件,或者不同的部件布置。
206.在一些实施例中,所述电子设备3是一种能够按照事先设定或存储的指令,自动进行数值计算和/或信息处理的电子设备,其硬件包括但不限于微处理器、专用集成电路、可编程门阵列、数字处理器及嵌入式设备等。所述电子设备3还可包括客户设备,所述客户设备包括但不限于任何一种可与客户通过键盘、鼠标、遥控器、触摸板或声控设备等方式进行人机交互的电子产品,例如,个人计算机、平板电脑、智能手机、数码相机等。
207.需要说明的是,所述电子设备3仅为举例,其他现有的或今后可能出现的电子产品如可适应于本发明,也应包含在本发明的保护范围以内,并以引用方式包含于此。
208.在一些实施例中,所述存储器31用于存储程序代码和各种数据,例如安装在所述电子设备3中的软件更新装置20,并在电子设备3的运行过程中实现高速、自动地完成程序或数据的存取。所述存储器31包括只读存储器(read-only memory,rom)、可编程只读存储器(programmable read-only memory,prom)、可擦除可编程只读存储器(erasable programmable read-only memory,eprom)、一次可编程只读存储器(one-time programmable read-only memory,otprom)、电子擦除式可复写只读存储器(electrically-erasable programmable read-only memory,eeprom)、只读光盘(compact disc read-only memory,cd-rom)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够
用于携带或存储数据的计算机可读的任何其他介质。
209.在一些实施例中,所述至少一个处理器32可以由集成电路组成,例如可以由单个封装的集成电路所组成,也可以是由多个相同功能或不同功能封装的集成电路所组成,包括一个或者多个中央处理器(central processing unit,cpu)、微处理器、数字处理芯片、图形处理器及各种控制芯片的组合等。所述至少一个处理器32是所述电子设备3的控制核心(control unit),利用各种接口和线路连接整个电子设备3的各个部件,通过运行或执行存储在所述存储器31内的程序或者模块,以及调用存储在所述存储器31内的数据,以执行电子设备3的各种功能和处理数据。
210.在一些实施例中,所述至少一条通信总线33被设置为实现所述存储器31以及所述至少一个处理器32等之间的连接通信。
211.尽管未示出,所述电子设备3还可以包括给各个部件供电的电源(比如电池),可选的,电源可以通过电源管理装置与所述至少一个处理器32逻辑相连,从而通过电源管理装置实现管理充电、放电、以及功耗管理等功能。电源还可以包括一个或一个以上的直流或交流电源、再充电装置、电源故障检测电路、电源转换器或者逆变器、电源状态指示器等任意组件。所述电子设备3还可以包括多种传感器、蓝牙模块、wi-fi模块等,在此不再赘述。
212.应该了解,所述实施例仅为说明之用,在专利申请范围上并不受此结构的限制。
213.上述以软件功能模块的形式实现的集成的单元,可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,电子设备,或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分。
214.在进一步的实施例中,结合图2,所述至少一个处理器32可执行所述电子设备3的操作装置以及安装的各类应用程序(如所述的软件更新装置20)、程序代码等,例如,上述的各个模块。
215.所述存储器31中存储有程序代码,且所述至少一个处理器32可调用所述存储器31中存储的程序代码以执行相关的功能。例如,图2中所述的各个模块是存储在所述存储器31中的程序代码,并由所述至少一个处理器32所执行,从而实现所述各个模块的功能以达到软件更新的目的。
216.示例性的,所述程序代码可以被分割成一个或多个模块/单元,所述一个或者多个模块/单元被存储在所述存储器31中,并由所述处理器32执行,以完成本技术。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机可读指令段,该指令段用于描述所述程序代码在所述电子设备3中的执行过程。例如,所述程序代码可以被分割成获取模块201、解析模块202、提取模块203、第一更新模块204、第一检查模块205、第二检查模块206及第二更新模块207。
217.在本发明的一个实施例中,所述存储器31存储多个计算机可读指令,所述多个计算机可读指令被所述至少一个处理器32所执行以实现软件更新的功能。
218.具体地,所述至少一个处理器32对上述指令的具体实现方法可参考图1对应实施例中相关步骤的描述,在此不赘述。
219.在本发明所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述模块的划分,仅
仅为一种逻辑功能划分,实际实现时可以有另外的划分方式。
220.所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理单元,既可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。
221.另外,在本发明各个实施例中的各功能模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用硬件加软件功能模块的形式实现。
222.对于本领域技术人员而言,显然本发明不限于上述示范性实施例的细节,而且在不背离本发明的精神或基本特征的情况下,能够以其他的具体形式实现本发明。因此,无论从哪一点来看,均应将实施例看作是示范性的,而且是非限制性的,本发明的范围由所附权利要求而不是上述说明限定,因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外,显然“包括”一词不排除其他单元或,单数不排除复数。本发明中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一,第二等词语用来表示名称,而并不表示任何特定的顺序。
223.最后应说明的是,以上实施例仅用以说明本发明的技术方案而非限制,尽管参照较佳实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,可以对本发明的技术方案进行修改或等同替换,而不脱离本发明技术方案的精神和范围。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1