一种构建依赖方法和装置与流程

1.本发明涉及软件开发技术领域，特别是涉及一种构建依赖方法和一种构建依赖装置。


背景技术：

2.aar(android archive)是一个android源码库的二进制归档文件，不仅包含了java文件，还包含资源文件、androidmanifest.xml以及build.gradle配置文件等。一个aar其实就是一个android源码库(包括代码、资源和配置文件)的打包归档文件。
3.gradle是一个基于jvm(java virtual machine，java虚拟机)的自动化构建开源工具，它使用一种基于groovy的特定领域语言(dsl)来声明项目设置，支持传递性依赖管理，抛弃了基于xml的各种繁琐配置。
4.现有技术中，在对工程中的业务线构建依赖时，可以通过如下方式实现：
5.1)在业务线的gradle配置文件build.gradle中添加aar依赖；
6.2)在工程根目录下的config.gradle文件中统一配置aar依赖，然后各业务线获取全局对象下定义的aar依赖。
7.但是，上述方式分别存在以下缺陷：
8.1)由于历史的迭代，每个业务线使用的aar依赖在整体项目中经常出现包名相同而版本号不一致的问题，从而直接导致了依赖冲突无法正常合并编译。比如，业务线biz_1中的a＝a1，biz_2中的a＝a2，此时，biz_1和biz_2依赖了相同的aar，即“a”是相同的，但是版本号1和2不同；
9.2)各业务线的依赖很容易被其他业务线篡改，无法管理，而且，依赖库不能设置修改权限，依赖库公用时会出现一方修改版本号其他业务线依赖被强制升级的问题。


技术实现要素：

10.鉴于上述问题，提出了本发明实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种构建依赖方法和相应的一种构建依赖装置。
11.为了解决上述问题，本发明实施例公开了一种构建依赖方法，其特征在于，所述方法包括：
12.获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；
13.获取所述业务线所需的目标公有依赖组对应的目标私有依赖；
14.构建所述业务线与所述目标私有依赖的依赖关系。
15.在一个或多个实施例中，所述获取所述业务线所需的目标公有依赖组对应的目标私有依赖，包括：
16.从所述工程配置文件中查找所述业务线所需的目标公有依赖组；
17.获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式；
18.获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件。
19.在一个或多个实施例中，所述获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件，包括：
20.针对所述至少一个目标私有依赖中的任一目标私有依赖，若所述依赖模式为工程源码模式，则获取所述任一目标私有依赖的工程源码依赖文件；
21.若所述依赖模式为安卓归档模式，则获取所述任一目标私有依赖的安卓归档依赖文件。
22.在一个或多个实施例中，所述获取所述任一目标私有依赖的工程源码依赖文件，包括：
23.通过findproject()方法获取所述任一目标私有依赖的工程源码依赖文件；
24.所述获取所述任一目标私有依赖的安卓归档依赖文件，包括：
25.通过rootproject.ext方法获取所述任一目标私有依赖的安卓归档依赖文件。
26.在一个或多个实施例中，所述工程配置文件中还记录有所述依赖模式；所述依赖模式定义在所述工程的模式配置文件中；
27.所述获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式，包括：
28.从所述模式配置文件中获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式。
29.在一个或多个实施例中，所述多个公有依赖组定义在所述工程配置文件中的ext对象中，所述多个私有依赖定义在所述工程配置文件中的ext对象之外。
30.相应的，本发明实施例公开了一种构建依赖装置，其特征在于，所述装置包括：
31.获取模块，用于获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；
32.所述获取模块，还用于获取所述业务线所需的目标公有依赖组对应的目标私有依赖；
33.构建模块，用于构建所述业务线与所述目标私有依赖的依赖关系。
34.在一个或多个实施例中，所述获取模块，包括：
35.查找子模块，用于从所述工程配置文件中查找所述业务线所需的目标公有依赖组；
36.模式获取子模块，用于获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式；
37.依赖获取子模块，用于获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件。
38.在一个或多个实施例中，所述依赖获取子模块，具体用于：
39.针对所述至少一个目标私有依赖中的任一目标私有依赖，若所述依赖模式为工程
源码模式，则获取所述任一目标私有依赖的工程源码依赖文件；若所述依赖模式为安卓归档模式，则获取所述任一目标私有依赖的安卓归档依赖文件。
40.在一个或多个实施例中，所述依赖获取子模块，具体用于：
41.通过findproject()方法所述任一目标私有依赖的工程源码依赖文件；
42.以及，
43.通过rootproject.ext方法获取所述任一目标私有依赖的安卓归档依赖文件。
44.在一个或多个实施例中，所述工程配置文件中还记录有所述依赖模式；所述依赖模式定义在所述工程的模式配置文件中；
45.所述模式获取子模块，具体用于：
46.从所述模式配置文件中获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式。
47.在一个或多个实施例中，所述多个公有依赖组定义在所述工程配置文件中的ext对象中，所述多个私有依赖定义在所述工程配置文件中的ext对象之外。
48.相应的，本发明实施例公开了一种电子设备，包括：处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现上述构建依赖方法实施例的各个步骤。
49.相应的，本发明实施例公开了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现上述构建依赖方法实施例的各个步骤。
50.本发明实施例包括以下优点：
51.获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；然后获取所述业务线所需的目标公有依赖组对应的目标私有依赖，并构建所述业务线与所述目标私有依赖的依赖关系。这样，将所有的单个依赖与全局对象存入在同一个工程配置文件中，而且，将所有的单个依赖统一定义在全局对象之外，从而可以对所有的单个依赖进行统一管理，避免了同一个依赖出现多个版本冲突的问题。同时，也正是由于将所有的单个依赖统一定义在全局对象之外，导致业务线无法直接访问单个依赖，而是访问包括多个单个依赖的公有依赖组，所以，业务线无法直接对单个依赖进行篡改，也无法直接访问单个依赖，从而解决了单个依赖无法管理，以及单个依赖公用时会出现一方修改版本号其他业务线依赖被强制升级的问题。
附图说明
52.图1是本发明的一种构建依赖方法实施例的步骤流程图；
53.图2是本发明的一种构建依赖方法的结构框架示意图一；
54.图3是本发明的一种构建依赖方法的结构框架示意图二；
55.图4是本发明的一种构建依赖装置实施例的结构框图。
具体实施方式
56.为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
57.本发明实施例的核心构思之一在于，获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；然后获取所述业务线所需的目标公有依赖组对应的目标私有依赖，并构建所述业务线与所述目标私有依赖的依赖关系。这样，将所有的单个依赖与全局对象存入在同一个工程配置文件中，而且，将所有的单个依赖统一定义在全局对象之外，从而可以对所有的单个依赖进行统一管理，避免了同一个依赖出现多个版本冲突的问题。同时，也正是由于将所有的单个依赖统一定义在全局对象之外，导致业务线无法直接访问单个依赖，而是访问包括多个单个依赖的公有依赖组，所以，业务线无法直接对单个依赖进行篡改，也无法直接访问单个依赖，从而解决了单个依赖无法管理，以及单个依赖公用时会出现一方修改版本号其他业务线依赖被强制升级的问题。
58.参照图1，示出了本发明的一种构建依赖方法实施例的步骤流程图，具体可以包括如下步骤：
59.步骤101，获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；
60.具体而言，工程可以是需要构建依赖的目标对象。在构建依赖时，可以在gradle中进行构建，也就是说，可以通过gradle获取工程的工程配置文件。其中，gradle是一个基于jvm(java virtual machine，java虚拟机)的自动化构建开源工具，它使用一种基于groovy的特定领域语言(dsl)来声明项目设置，支持传递性依赖管理，抛弃了基于xml的各种繁琐配置。
61.进一步，工程配置文件可以是config.gradle，config.gradle可以是build.gradle的下一级配置文件。在该工程配置文件中，记录有多个私有依赖和多个公有依赖组，每个公有依赖组包括多个私有依赖中的至少一个。
62.比如，私有依赖为a、b、c，公有依赖组biz_1包括a、b、c，公有依赖组biz_2包括a。
63.在本发明实施例中，所述多个公有依赖组定义在所述工程配置文件中的ext对象中，所述多个私有依赖定义在所述工程配置文件中的ext对象之外。
64.具体而言，工程配置文件提供了一个全局对象，即ext对象，在全局对象中，可以定义各个公有依赖组包括的至少一个私有依赖。而在ext对象之外，可以通过def字段定义各个私有依赖。
65.比如，某个config.gradle的具体内容如下：
[0066][0067]
其中，a、b、c为定义在ext全局对象之外的私有依赖，biz_1和biz_2为定义在ext全局对象中的公有依赖组，biz_1包括私有依赖a、b、c，biz_2包括私有依赖a，a1为a的参数值，b1为b的参数值，c1为c的参数值。
[0068]
进一步，工程可以包括业务线，业务线具有对应的业务线配置文件，业务线配置文件也可以是build.gradle，业务线配置文件中记录有该业务线需要的公有依赖组。比如，某个业务线的build.gradle内容为：rootproject.ext.biz_1，那么就表示该业务线需要的公有依赖组为biz_1。
[0069]
需要说明的是，工程具有对应的工程接口，通过该工程接口可以访问该工程中的业务线。而且，该工程接口的配置文件中记录了获取公有依赖组的方法，也就是上例中的“rootproject.ext”。
[0070]
进一步，工程配置文件中的私有依赖可以被该工程配置文件中的公有依赖组访问，但是无法被其它工程配置文件中的公有依赖组访问，这样，就将所有的单个依赖与ext全局对象存入在同一个config.gradle中，而且，通过def字段定义的方式统一定义在ext全局对象之外，从而可以对所有的单个依赖进行统一管理，避免了同一个依赖出现多个版本冲突的问题。
[0071]
为方便理解，图2示出了工程、工程接口、业务线、工程配置文件及内容、工程接口的配置文件及内容、业务线的配置文件及内容的示意图，具体可参考上述内容，为避免重复，在此就不赘述了。
[0072]
步骤102，获取所述业务线所需的目标公有依赖组对应的目标私有依赖；
[0073]
在获取到业务线配置文件之后，即可根据业务线配置文件来获取业务线需要的目标公有依赖组，以及该目标公有依赖组中的目标私有依赖。
[0074]
在本发明实施例中，所述获取所述业务线所需的目标公有依赖组对应的目标私有
依赖，包括：
[0075]
从所述工程配置文件中查找所述业务线所需的目标公有依赖组；
[0076]
获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式；
[0077]
获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件。
[0078]
具体而言，在获取到业务线配置文件后，确定出业务线配置文件中记录的目标公有依赖组，然后从工程配置文件中查找该目标公有依赖组，找到之后，获取该目标公有依赖组中每个私有依赖各自对应的依赖模式，并基于每个私有依赖的依赖模式获取对应的依赖文件。
[0079]
在本发明实施例中，所述工程配置文件中还记录有所述依赖模式；所述依赖模式定义在所述工程的模式配置文件中；
[0080]
所述获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式，包括：
[0081]
从所述模式配置文件中获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式。
[0082]
具体而言，工程配置文件中还记录有依赖模式(dependencymode)，而依赖模式定义在工程的模式配置文件(settings.gradle)中。
[0083]
比如，工程settings.gradle的具体内容如下：
[0084]
include switches["m"]？"":"m"
[0085]
include switches["n"]？"":"n"
[0086]
其中，定义了m和n两种依赖模式。
[0087]
而依赖模式记录在工程配置文件中ext对象之外。比如，工程config.gradle的具体内容如下：
[0088][0089]
其中，switches中记录了依赖模式m的参数值为aar(android archive，安卓归档)，表示aar模式，依赖模式n的参数值为空，表示工程源码模式，以及，公有依赖组biz_1中的私有依赖a采用aar模式，私有依赖b采用工程源码模式，私有依赖c没有记录依赖模式，则采用默认的依赖模式即可。
[0090]
这样，在查找到公有依赖组后，即可获取各个私有依赖各自对应的依赖模式。比如，在查找到biz_1后，即可获取a、b、c各自对应的依赖模式。
[0091]
在本发明实施例中，所述获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件，包括：
[0092]
针对所述至少一个目标私有依赖中的任一目标私有依赖，若所述依赖模式为工程源码模式，则获取所述任一目标私有依赖的工程源码依赖文件；
[0093]
若所述依赖模式为安卓归档模式，则获取所述任一目标私有依赖的安卓归档依赖文件。
[0094]
具体而言，针对各个私有依赖中的任一私有依赖，若该任一私有依赖的依赖模式为工程源码模式，则获取该任一目标私有依赖的工程源码依赖文件；若该任一私有依赖的依赖模式为aar模式，则获取该任一目标私有依赖的aar依赖文件。依此类推，即可获取业务线所需的所有依赖文件。
[0095]
在本发明实施例中，所述获取所述任一目标私有依赖的工程源码依赖文件，包括：
[0096]
通过findproject()方法所述任一目标私有依赖的工程源码依赖文件；
[0097]
所述获取所述任一目标私有依赖的安卓归档依赖文件，包括：
[0098]
通过rootproject.ext方法获取所述任一目标私有依赖的安卓归档依赖文件。
[0099]
具体而言，在获取工程源码依赖文件时，可以采用系统的findproject()方法来获取，在获取aar依赖文件时，可以采用系统的rootproject.ext方法来获取。
[0100]
为方便理解，图3示出了工程、工程接口、业务线、工程配置文件及内容、工程接口的配置文件及内容、业务线的配置文件及内容、模式配置文件及内容的示意图，具体可参考上述内容，为避免重复，在此就不赘述了。
[0101]
这样，通过定义多个依赖模式的方式，使得对业务线构建依赖更加简易、灵活和安全，尤其是在业务线数量较多的时候，效果更加明显。
[0102]
步骤103，构建所述业务线与所述目标私有依赖的依赖关系。
[0103]
具体而言，在获取到业务线所需的所有目标私有依赖后，构建业务线与所有目标私有依赖的依赖关系，这样，业务线即可访问所有目标私有依赖的参数值。
[0104]
在本发明实施例中，获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；然后获取所述业务线所需的目标公有依赖组对应的目标私有依赖，并构建所述业务线与所述目标私有依赖的依赖关系。这样，将所有的单个依赖与全局对象存入在同一个工程配置文件中，而且，将所有的单个依赖统一定义在全局对象之外，从而可以对所有的单个依赖进行统一管理，避免了同一个依赖出现多个版本冲突的问题。同时，也正是由于将所有的单个依赖统一定义在全局对象之外，导致业务线无法直接访问单个依赖，而是访问包括多个单个依赖的公有依赖组，所以，业务线无法直接对单个依赖进行篡改，也无法直接访问单个依赖，从而解决了单个依赖无法管理，以及单个依赖公用时会出现一方修改版本号其他业务线依赖被强制升级的问题。
[0105]
需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明实施例并不受所描述的动作顺序的限制，因为依据本发明实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本发明实施例所必须的。
[0106]
参照图4，示出了本发明的一种构建依赖装置实施例的结构框图，具体可以包括如下模块：
[0107]
获取模块401，用于获取工程的工程配置文件，以及，所述工程中业务线的业务线配置文件；其中，所述工程配置文件记录有多个私有依赖和多个公有依赖组，所述多个公有依赖组中的任一公有依赖组包括所述多个私有依赖中的至少一个；所述业务线配置文件记录有所述业务线所需的目标公有依赖组；
[0108]
所述获取模块，还用于获取所述业务线所需的目标公有依赖组对应的目标私有依赖；
[0109]
构建模块402，用于构建所述业务线与所述目标私有依赖的依赖关系。
[0110]
在本发明实施例中，所述获取模块，包括：
[0111]
查找子模块，用于从所述工程配置文件中查找所述业务线所需的目标公有依赖组；
[0112]
模式获取子模块，用于获取所述目标公有依赖组中至少一个目标私有依赖对应的
至少一个依赖模式；
[0113]
依赖获取子模块，用于获取所述至少一个目标私有依赖在对应的依赖模式下的依赖文件。
[0114]
在本发明实施例中，所述依赖获取子模块，具体用于：
[0115]
针对所述至少一个目标私有依赖中的任一目标私有依赖，若所述依赖模式为工程源码模式，则获取所述任一目标私有依赖的工程源码依赖文件；若所述依赖模式为安卓归档模式，则获取所述任一目标私有依赖的安卓归档依赖文件。
[0116]
在本发明实施例中，所述依赖获取子模块，具体用于：
[0117]
通过findproject()方法所述任一目标私有依赖的工程源码依赖文件；
[0118]
以及，
[0119]
通过rootproject.ext方法获取所述任一目标私有依赖的安卓归档依赖文件。
[0120]
在本发明实施例中，所述工程配置文件中还记录有所述依赖模式；所述依赖模式定义在所述工程的模式配置文件中；
[0121]
所述模式获取子模块，具体用于：
[0122]
从所述模式配置文件中获取所述目标公有依赖组中至少一个目标私有依赖对应的至少一个依赖模式。
[0123]
在本发明实施例中，所述多个公有依赖组定义在所述工程配置文件中的ext对象中，所述多个私有依赖定义在所述工程配置文件中的ext对象之外。
[0124]
对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0125]
本发明实施例还提供了一种电子设备，包括：
[0126]
包括处理器、存储器及存储在所述存储器上并能够在所述处理器上运行的计算机程序，该计算机程序被处理器执行时实现上述构建依赖方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0127]
本发明实施例还提供了一种计算机可读存储介质，计算机可读存储介质上存储计算机程序，计算机程序被处理器执行时实现上述构建依赖方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。
[0128]
本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
[0129]
本领域内的技术人员应明白，本发明实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本发明实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
[0130]
本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执
行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
[0131]
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
[0132]
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
[0133]
尽管已描述了本发明实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
[0134]
最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
[0135]
以上对本发明所提供的一种构建依赖方法和一种构建依赖装置，进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。