一种加载组件的方法和装置与流程

文档序号:14722467发布日期:2018-06-17 21:31阅读:240来源:国知局

本发明涉及计算机应用技术,尤其涉及一种加载组件的方法和装置。



背景技术:

在大型互联网产品的持续集成方面,不论是产品过程改进,还是私有化定制的业务需求,多分支并行开发及发布的模式已经越来越流行。在同一项目中,通过加载众多的组件,来提供相应的功能,其中,组件是应用系统架构中可复用的功能模块,可通过JAR文件(JavaArchive,Java归档文件)等来实现。

在现有的gradle项目中,为避免在分支合并时,build.gradle配置文件因组件版本的不同采用冲突,一般是把依赖组件的版本号配成固定值,然而,随着应用规模的加大,自行开发的功能、各种第三方软件开发的功能会同时使用同一组件的不同版本,若依旧在多分支使用组件的同一固定版本的情况下,依赖于该组件其他版本的功能会失效。



技术实现要素:

本发明实施例提供了一种加载组件的方法和装置,可根据分支动态获取其所依赖组件的版本标识,以加载对应的组件,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

本发明实施例提供了一种加载组件的方法,包括:

预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;

当刷新组件时,确定项目在所述本地git库所处的目标分支;

利用预定义配置文件,获取所述目标分支依赖的组件的版本标识;

根据所述目标分支依赖的组件的版本标识加载对应的组件。

本发明实施例第二方面提供了一种加载组件的装置,包括:

配置单元,用于预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;

确定单元,用于当刷新组件时,确定项目在所述本地git库所处的目标分支;

获取单元,用于利用预定义配置文件,获取所述目标分支依赖的组件的版本标识;

加载单元,用于根据所述目标分支依赖的组件的版本标识加载对应的组件。

本发明实施例提供的技术方案中,首先预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件,当刷新组件时,确定项目在所述本地git库所处的目标分支,并利用预定义配置文件获取目标分支依赖的组件的版本标识,再根据目标分支依赖的组件的版本标识加载对应的组件。因此相对于现有技术,本发明实施例可根据分支动态获取组件的版本标识,且通过预定义配置本地git库中各分支依赖的组件的版本标识,可实现各分支对组件版本的个性化依赖,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

附图说明

图1为本发明实施例中加载组件的方法一个实施例示意图;

图2为本发明实施例中加载组件的方法另一实施例示意图;

图3为本发明实施例中加载组件的装置一个实施例示意图;

图4为本发明实施例中加载组件的装置另一实施例示意图。

具体实施方式

本发明实施例提供了一种加载组件的方法和装置,可根据分支动态获取其所依赖组件的版本标识,以加载对应的组件,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本,以下分别进行详细说明。

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

请参阅图1,本发明实施例中加载组件的方法一个实施例包括:

101、预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;

在本实施例中,根据实际需求预先为本地git库中各分支配置其依赖的组件的版本标识,并保存得到的预定义配置文件。在通过上述预定义配置后,可根据预定义配置文件获取每个分支依赖的组件的版本标识。

102、当刷新组件时,确定项目在本地git库所处的目标分支;

在刷新组件时,如果项目已经创建了本地git库,则可以确定项目在该本地git库的分支,得到与该项目对应的目标分支。

103、利用预定义配置文件,获取目标分支依赖的组件的版本标识;

在预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件后,可以利用该预定义配置文件,获取目标分支依赖的组件的版本标识。

104、根据目标分支依赖的组件的版本标识加载对应的组件;

在获取目标分支依赖的组件的版本标识后,根据获取的版本标识加载对应目标分支依赖的组件。

本发明实施例提供的技术方案中,首先预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件,当刷新组件时,确定项目在所述本地git库所处的目标分支,并利用预定义配置文件获取目标分支依赖的组件的版本标识,再根据目标分支依赖的组件的版本标识加载对应的组件。因此相对于现有技术,本发明实施例可根据分支动态获取组件的版本标识,且通过预定义配置本地git库中各分支依赖的组件的版本标识,可实现各分支对组件版本的个性化依赖,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

下面在图1所示实施例的基础上,进一步对本发明实施例中加载组件的方法进行详细描述,具体请参阅图2,本发明实施例中加载组件的方法另一实施例包括:

需要说明的是,组件是应用系统架构中可复用的功能模块,在本实施例中,以jar文件为例进行描述,在实际应用过程中,还可以包括其他文件类型,具体此处不作限定。

201、预定义配置本地git库中各分支依赖的jar文件的版本标识,得到预定义配置文件;

在本实施例中,根据实际需求预先为本地git库中各分支配置其依赖的jar文件的版本标识,并保存得到的预定义配置文件。在通过上述预定义配置后,可根据预定义配置文件获取每个分支依赖的jar文件的版本标识。

202、通过解析项目的HEAD文件确定项目在本地git库所处的目标分支;

在本实施例中,可以通过获取项目的HEAD文件的信息获得分支名,以确定项目在本地git库所处的分支,得到与该项目对应的目标分支。

203、根据项目的本地目录获取common.libs目录的地址;

在本实施例中,根据该项目的本地目录可以获取common.libs配置的目录,以得到common.libs目录的地址。

204、通过地址获取预定义配置文件;

在得到common.libs目录的地址后,通过该地址可以获取预定义配置文件。common.libs统一管理公共配置信息,其主要包括两个配置文件,分别为common.gralde和dependencyVersion.properties,其中,common.gralde主要标明引用“java”插件、采用“UTF-8”编译java文件、配置用到的maven库以及获取版本标识的方法,dependencyVersion.properties包括预定义配置文件。

205、根据获取的预定义配置文件获取所述目标分支依赖的jar文件的版本标识;

在预定义配置本地git库中各分支依赖的jar文件的版本标识,得到预定义配置文件后,可以利用该预定义配置文件,获取目标分支依赖的jar文件的版本标识。

206、根据目标分支依赖的jar文件的版本标识更新build.gradle配置文件;

在gradle项目中,主要是通过build.gradle配置文件来获取项目依赖的jar文件,例如,build.gradle文件的构成可以是如下的形式:

其中,versionId表示jar文件的版本标识,在本实施例中,versionId为变量,以确保在刷新jar文件时,可根据分支获取相应的jar文件的版本标识。相应地,在本实施例中,jar文件可以采用如下书写格式:

“com.kdweibo:com.kdweibo.base.stakeholder:${versionId}”

其中“com.kdweibo”是groupId,“com.kdweibo.base.stakeholder”是artifactId,“${versionId}”为变量。

207、通过更新后的build.gradle配置文件加载对应的jar文件。

在根据目标分支依赖的jar文件的版本标识更新build.gradle配置文件后,更新后的build.gradle配置文件能准确反映当前分支所需加载的jar文件的版本。

可选地,在本实施例中,在步骤102之前还可以包括:

判断项目是否创建了本地git库,若是,则执行确定该项目在本地git库所处的目标分支的步骤,若否,默认项目在本地git库所处的目标分支为master分支。

本发明实施例提供的技术方案中,首先预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件,当刷新组件时,确定项目在所述本地git库所处的目标分支,并利用预定义配置文件获取目标分支依赖的组件的版本标识,再根据目标分支依赖的组件的版本标识加载对应的组件。因此相对于现有技术,本发明实施例可根据分支动态获取组件的版本标识,且通过预定义配置本地git库中各分支依赖的组件的版本标识,可实现各分支对组件版本的个性化依赖,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

上面对本发明实施例中的加载组件的方法进行了描述,下面对本发明实施例中的加载组件的装置进行描述,请参阅图3,本发明实施例中加载组件的装置一个实施例包括:

配置单元301,用于预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;

确定单元302,用于当刷新组件时,确定项目在所述本地git库所处的目标分支;

获取单元303,用于利用预定义配置文件,获取所述目标分支依赖的组件的版本标识;

加载单元304,用于根据所述目标分支依赖的组件的版本标识加载对应的组件。

为便于理解,下面以一具体应用场景为例,对本实施例中加载组件的装置内部运作流程进行描述:

配置单元301预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;当刷新组件时,确定单元302确定项目在所述本地git库所处的目标分支;获取单元303利用预定义配置文件,获取所述目标分支依赖的组件的版本标识;加载单元304根据所述目标分支依赖的组件的版本标识加载对应的组件。

本发明实施例提供的技术方案中,首先由配置单元301预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件,当刷新组件时,由确定单元302确定项目在所述本地git库所处的目标分支,并通过获取单元303利用预定义配置文件获取目标分支依赖的组件的版本标识,再由加载单元304根据目标分支依赖的组件的版本标识加载对应的组件。因此相对于现有技术,本发明实施例可根据分支动态获取组件的版本标识,且通过预定义配置本地git库中各分支依赖的组件的版本标识,可实现各分支对组件版本的个性化依赖,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

下面在图3所示实施例的基础上,进一步对本发明实施例中加载组件的装置的结构进行详细描述,具体请参阅图4,本发明实施例中加载组件的装置另一实施例包括:

配置单元401,用于预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件;

确定单元402,用于当刷新组件时,确定项目在所述本地git库所处的目标分支;

获取单元403,用于利用预定义配置文件,获取所述目标分支依赖的组件的版本标识;

加载单元404,用于根据所述目标分支依赖的组件的版本标识加载对应的组件。

在本实施例中,所述确定单元402,具体用于通过解析所述项目的HEAD文件确定项目在所述本地git库所处的目标分支。

所述获取单元403可以包括:

第一获取模块4031,用于根据所述项目的本地目录获取common.libs目录的地址;

第二获取模块4032,用于通过所述地址获取所述预定义配置文件;

第三获取模块4033,用于根据获取的所述预定义配置文件获取所述目标分支依赖的组件的版本标识。

可选地,在本实施例中,所述加载单元404可以包括:

更新模块4041,用于根据所述目标分支依赖的组件的版本标识更新build.gradle配置文件;

加载模块4042,用于通过更新后的build.gradle配置文件加载对应的组件。

可选地,在本实施例中,所述装置还可以包括:

判断单元405,用于判断所述项目是否创建了本地git库;

所述确定单元402,还用于在判断所述项目已经创建了本地git库时,确定项目在所述本地git库所处的目标分支,在判断所述项目未创建本地git库时,默认所述项目在所述本地git库所处的目标分支为master分支。

本发明实施例提供的技术方案中,首先由配置单元401预定义配置本地git库中各分支依赖的组件的版本标识,得到预定义配置文件,当刷新组件时,由确定单元402确定项目在所述本地git库所处的目标分支,并通过获取单元403利用预定义配置文件获取目标分支依赖的组件的版本标识,再由加载单元404根据目标分支依赖的组件的版本标识加载对应的组件。因此相对于现有技术,本发明实施例可根据分支动态获取组件的版本标识,且通过预定义配置本地git库中各分支依赖的组件的版本标识,可实现各分支对组件版本的个性化依赖,使得开发调试时实现一键更新,自动、准确找到所依赖的组件版本。

所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。

在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述,以上实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1