一种依赖项目管理工具自定义引用流程的方法及设备

技术领域

本发明涉及计算机技术领域，尤其涉及一种依赖项目管理工具自定义引用流程的方法及设备。

背景技术

目前，多模块开发的场景中，缺少多模块之间的引用，缺少公共引用源管理，在现有引用过程中，引用方和使用方是紧耦合的，开发人员无法通过自助的形式完成引用过程。模型间依赖没有工具支撑，必须手动拷贝引用包，手动拷贝容易出错且不利于产品的传递，局限性大。

另外，存在开发人员自建规则与系统，提供内容引用，但是无法与通用的基础设施融合的情况。

发明内容

本说明书一个或多个实施例提供一种依赖项目管理工具自定义引用流程的方法及设备。用以解决如下技术问题：引用包必须手动拷贝并且无法与通用的基础设施融合的问题。

为解决上述技术问题，本说明书一个或多个实施例是这样实现的：

第一方面，本说明书一种依赖项目管理工具自定义引用流程的方法，包括：

对模型进行开发产生模型包与代码工程包，所述模型包与所述代码工程包对应；

在模型描述文件中对所述模型包进行模型依赖描述得到模型依赖信息；

在代码工程描述文件中对所述代码工程包进行代码工程依赖描述，得到代码工程依赖信息；

打包和部署所述模型包与所述代码工程包，将所述模型包添加到项目管理工具中，同时推送所述模型包与所述代码工程包；

根据所述模型依赖信息添加所述模型包引用，添加与所述模型包对应的代码工程包引用。

通过对模型包与代码工程包进行依赖描述，并打包模型包与代码工程包，定义引用包，将模型包添加到项目管理工具中，推送模型包，根据依赖信息进行模型包引用，定义引用流程。使得提供引用的一方对外推包，使用的一方能够从公共的位置按照公共的规则获取包。

可选地，移除所述模型包引用，移除与所述模型包对应的代码工程包引用。

可选地，获取所述模型依赖信息，判断所述模型包是否存在；

若存在，移除所述模型依赖信息，移除与所述模型包对应的所述jar包的所述代码工程依赖信息。

所述模型依赖信息包括模型包所属组、模型包唯一标识、模型包版本号；

其中，所述模型包所属组、所述模型包唯一标识、所述模型包版本号确定所述模型的唯一性。

可选地，所述代码工程依赖信息包括：代码工程包所属组、代码工程包唯一标识、代码工程包版本号；

其中，所述代码工程包版本号使用预先设置的规则与所述模型包版本号进行对应。

可选地，所述模型包所属组与所述代码工程包所属组相同，所述模型包唯一标识与所述代码工程包唯一标识相同。

模型包唯一标识与代码工程包唯一标识相同，确定唯一性，确保代码工程包与模型包能够通过预设规则进行对应。

可选地，所述打包和部署所述模型包与所述代码工程包，具体包括：

判断所述模型包与所述代码工程包是否存在；

若存在，读取所述模型描述文件，获取所述模型依赖信息；

创建特定文件，在所述特定文件中添加所述模型依赖信息以及打包相关配置信息；

根据所述模型依赖信息与所述打包相关配置信息执行打包过程。

可选地，所述打包相关配置信息包括打包类型信息，插件的配置信息；

所述插件拓展所述项目管理工具的打包机制，执行所述项目管理工具打包过程。

可选地，所述根据所述模型依赖信息与所述打包相关配置信息执行打包过程，具体包括：

获取所述插件的配置信息；

获取待打包文件，所述待打包文件包括所述模型包与所述代码工程包；

获取所述打包类型信息，使用所述插件将所述待打包文件压缩打包。

第二方面，本说明书一个或多个实施例一种依赖项目管理工具自定义引用流程的设备，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行：

对模型进行开发产生模型包与代码工程包，所述模型包与所述代码工程包对应；

在模型描述文件中对所述模型包进行模型依赖描述得到模型依赖信息；

在代码工程描述文件中对所述代码工程包进行代码工程依赖描述，得到代码工程依赖信息；

打包和部署所述模型包与所述代码工程包，将所述模型包添加到项目管理工具中，同时推送所述模型包与所述代码工程包；

根据所述模型依赖信息添加所述模型包引用，然后添加与所述模型包对应的代码工程包引用。

本说明书一个或多个实施例提供一种依赖项目管理工具自定义引用流程的方法及设备，通过该方案，解决了引用包必须手动拷贝并且无法与通用的基础设施融合的问题。借鉴项目管理工具的引用机制，扩展了项目管理工具的打包方式，将建模过程中模型封装成可供项目管理工具管理、识别的包，将产物交给项目管理工具管理，提高了包管理效率，提升便捷性。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书一个或多个实施例提供的一种依赖项目管理工具自定义引用流程的方法流程示意图；

图2为本说明书一个或多个实施例提供的模型包与代码工程包关系图；

图3为本说明书一个或多个实施例提供的一种打包部署模型包与代码工程包的流程示意图；

图4为本说明书一个或多个实施例提供的一种打包部署模型包与代码工程包的执行过程示意图；

图5为本说明书一个或多个实施例提供的一种移除模型包引用和代码工程包引用的流程示意图；

图6为本说明书一个或多个实施例提供的一种依赖项目管理工具自定义引用流程的设备的结构示意图。

具体实施方式

本说明书实施例提供一种依赖项目管理工具自定义引用流程的方法及设备。

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

以下结合附图，详细说明本说明书各实施例提供的技术方案。

在本说明书的各实施例中，项目管理工具以maven为例，代码工程包以jar包为例，进行举例说明。

图1为本说明书一个或多个实施例提供的一种依赖项目管理工具自定义引用流程的方法流程示意图，具体包括以下步骤：

S101：对模型进行开发产生模型包与代码工程包，所述模型包与所述代码工程包对应。

在本说明书一个或多个实施例中，开发人员开发模型使用的工具不做限定。开发人员开发模型，模型开发完成后有模型的产物，模型的产物包括模型包和代码工程包。其中，模型包modelPackage，简称mdpkg，代码工程包主要包含了生产的代码，以jar包为例，对于同一个模型，模型包mdpkg与jar包有相同的唯一标识，模型包mdpkg与jar包对应。

S102：在模型描述文件中对所述模型包进行模型依赖描述得到模型依赖信息。

在本说明书一个或多个实施例中，模型依赖信息包括模型包所属组、模型包唯一标识、模型包版本号，其中，模型包所属组、模型包唯一标识、模型包版本号确定模型的唯一性。

模型包作为模型的产物，需要融合到maven体系中，在模型描述文件中可以对模型包进行模型依赖描述，模型描述文件可以命名为mdproj，可以理解的是，模型描述文件名称可以自定义，在此不做限定。模型描述文件mdproj中依赖描述信息包括groupId，artifactId，version。

其中，groupId定义了模型包所属组，artifactId定义了模型包的唯一标志，version定义了模型包的版本号。所属组groupId，唯一标识artifactId和版本version为依赖的基本坐标，需要说明的是，基本坐标是唯一的。对于任何一个依赖来说，基本坐标是最重要的，maven根据坐标才能找到需要的依赖。在maven管理体系中，存在多个模型，多个模型的基本坐标互不相同，由所属组groupId，唯一标识artifactId和版本号version构成的依赖的基本坐标确认在maven管理体系中模型的唯一性。

S103：在代码工程描述文件中对所述代码工程包进行代码工程依赖描述，得到代码工程依赖信息。

在本说明书的一个或多个实施例中，代码工程依赖信息包括代码工程包所属组、代码工程包唯一标识、代码工程包版本号，其中，代码工程包版本号使用预先设置的规则与模型包版本号进行对应。

maven默认产物类型为jar，在代码工程描述文件中对jar包进行代码工程依赖描述，代码工程依赖描述信息中包括jar包所属组、jar包唯一标识、jar包版本号，需要说明的是，jar包所属组、jar包唯一标识、jar包版本号，也能够唯一确定一个jar包。其中，jar包版本号使用预先设置的规则与模型包版本号进行对应，预设规则可以为在模型包版本号的后面或者前面添加字母，例如，模型包版本号为0.1.1，jar包版本号根据规则可以为M0.1.1或者0.1.1M，可以理解的是，添加的字母可以为任意的，若模型包版本号为0.1.1，jar包版本号也可以为J0.1.1或者0.1.1J。需要说明的是，模型包版本号不限定于上述实施例，模型包版本号还可以为1.1等。同样的，预设规则也不仅限定于上述实施例，预设规则还可以为在模型包版本号的下方添加下划线或者在模型包版本号的前面或者后面添加特定字符，在此不做具体限定。

在本说明书的一个或多个实施例中，模型包所属组与代码工程包所属组相同，模型包唯一标识与代码工程包唯一标识相同。

图2为本说明书一个或多个实施例提供的模型包与代码工程包关系图，其中模型包mdpkg与jar包并列，具有相同的artifactld，其中artifactld定义唯一标志。模型包mdpkg与jar包也具有相同的groupld，groupld定义所属组。模型包mdpkg与jar包具有相同的所属组与唯一标识，并且jar包版本号使用预先设置的规则与模型包版本号进行对应，在后续推送过程中，便于将jar包与模型包mdpkg同时推送，保证jar包和模型包的对应，避免出现jar包与模型包不对应，出现引用出错的情况。

S104：打包和部署所述模型包与所述代码工程包，将所述模型包添加到项目管理工具中，同时推送所述模型包与所述代码工程包。

在描述了模型包依赖信息与jar包依赖信息之后，需要借鉴maven引用机制，扩展maven打包机制，将模型包添加到maven管理机制中，以供maven管理、识别，同时推送模型包和jar包，提高模型包管理效率，提升便捷性。

图3为本说明书一个或多个实施例提供的一种打包部署模型包与代码工程包的流程示意图。

在本说明书的一个或多个实施例中，判断模型包与代码工程包是否存在；若存在，读取模型描述文件，获取模型依赖信息；创建特定文件，在特定文件中添加模型依赖信息以及打包相关配置信息；根据模型依赖信息与打包相关配置信息执行打包过程。

具体的，以特定文件为pom.xml文件为例。判断模型包与代码工程包是否存在，若不存在，抛出异常，结束打包过程。若存在，读取模型描述文件mdproj中的模型依赖信息，创建pom.xml文件，在pom.xml文件中添加模型依赖信息以及打包相关配置信息。

其中，模型包pom.xml文件中添加了模型包的模型依赖信息，将模型包依赖描述时定义的所属组、唯一标识、版本号添加到pom.xml文件，需要说明的是，pom.xml文件中可以不止包含一个所属组、唯一标识、版本号，可以包含多个不同的所属组、唯一标识、版本号，当然pom.xml文件中也可以包含其他信息，比如依赖范围、依赖类型或者依赖是否可选等信息。

在本说明书的一个或多个实施例中，打包相关配置信息包括打包类型信息，插件配置信息，插件拓展项目管理工具的打包机制，执行项目管理工具打包过程。

在pom.xml文件中还需要添加打包相关配置信息，打包相关配置信息包括打包类型信息，插件配置信息。添加打包相关配置信息，是在pom.xml文件中添加定义属性，属性名称为打包类型、插件配置。其中，打包类型信息指定打包类型，如上述pom.xml文件示例，metadata-pack为打包类型信息，metadata-pack指定打包类型，类型为mdpkg，后缀为mdpkg。插件配置信息描述插件配置，businessmodel-maven-plugin为一个打包插件，该插件扩展了打包机制，融入了模型包类型，重写了package过程，也就是重写了打包过程，打包mdpkg类型。若打包部署模型包和代码工程成功，结束打包过程，引用包自定义完成，模型包和jar包成功融入到maven体系中，之后能够充分利用基础设施对依赖版本进行查找、管理，不需要手动拷贝依赖包并且能够与通用的基础设施融合，而且因为依赖描述的基本坐标确定了模型是唯一的，不需要重复开发相同的模型，需要模型引用时，直接在maven体系中通过基本坐标引用。若打包部署模型包和代码工程失败，抛出异常，结束打包过程。开发人员可重新描述mdproj中的依赖信息，重新进行打包过程，直到打包和部署模型包和代码工程成功。

图4为本说明书一个或多个实施例提供的一种打包部署模型包与代码工程包的执行过程示意图。

在本说明书的一个或多个实施例中，获取插件的配置信息；获取待打包文件，待打包文件包括模型包与代码工程包；获取打包类型信息，使用插件将待打包文件压缩打包。

具体的，执行打包后，首先获取插件配置，插件配置信息在pom.xml文件中，获取pom.xml文件中的插件配置，若获取插件配置失败，则抛出异常，结束打包执行。需要说明的是，开发人员在pom.xml文件中没有配置插件信息，或者开发人员在pom.xml文件中配置插件信息错误，都会获取插件配置失败，抛出异常，在此不做具体限定。

若获取插件配置成功，获取文件列表，从maven上下文中，获取工程中的文件，需要说明的是，工程中的文件包括整个工程中的所有文件，所有文件中包括模型包的文件、jar包的文件。获取打包类型信息，指获取文件类型、路径，文件类型中包括模型包类型，使用businessmodel-maven-plugin插件扩展maven打包机制，融入了模型包类型，将文件列表中的文件压缩打包，文件列表中包括模型包。

在将模型包和jar包压缩打包后，推送模型包和jar包，在推送过程中，会将模型包和jar包同时进行推送，保证jar包和模型包对应。

S105：根据所述模型依赖信息添加所述模型包引用，添加与所述模型包对应的代码工程包引用。

模型依赖信息确定了模型的唯一性与模型的基本坐标，maven根据基本坐标找到需要引用的模型包，模型依赖信息中包含版本号，jar包的版本号域模型包的版本号对应，可以根据添加的模型包引用，找到对应的jar包引用，然后添加与模型包对应的jar包引用。

通过依赖maven基础设施，进行模型引用，开发人员可通过自助的形式完成引用的过程。通过从公共的位置按照公共的规则获取提供引用的一方向外推送的模型包，避免了手动拷贝模型包，有利于产品的传递，应用范围广。并且通过从公共的位置按照公共的规则获取提供引用的一方向外推送的模型包，无需开发人员自建规则与系统，提供引用内容。

在本说明书的一个或多个实施例中，移除模型包引用，移除与模型包对应的代码工程包引用。

此外，本说明书的一个或多个实施例不仅可以模型包引用，还可以移除模型包引用。开发人员在开发过程中会创建各种模型，也会引入各种不同的模型包，在引入模型包过程中难免会引入不需要的模型包，此时可以通过移除模型包引用移除不需要的模型包。

图5为本说明书一个或多个实施例提供的一种移除模型包引用和代码工程包引用的流程示意图。

在本说明书的一个或多个实施例中，获取模型依赖信息，判断模型包是否存在，若存在，移除模型依赖信息，移除与模型包对应的jar包的代码工程依赖信息。

具体的，移除模型依赖信息，要卸载模型引用，首先获取模型依赖信息，判断模型包是否存在，若不存在，抛出异常，停止卸载模型引用流程。若判断模型包存在，移除模型描述文件mdproj中的模型依赖信息，同时移除与模型包对应的jar包代码工程依赖信息，至此卸载模型引用成功，结束卸载模型引用流程。

需要说明的是，在上述各实施例中，抛出异常的方式包括但不限于弹出对话框，将页面分割为左右两页或者上下两页，其中一页抛出异常，抛出异常时包含异常信息，异常信息可以定位异常位置，便于开发人员确定异常信息，快速解决异常，加快开发流程。

本说明书一个或多个实施例采用的上述至少一个技术方案，解决了引用包必须手动拷贝并且无法与通用的基础设施融合的问题。借鉴了maven引用机制，扩展了maven打包方式，将建模过程中模型封装成可供maven管理、识别的包，将产物交给maven管理，提高了包管理效率，提升便捷性，并且使用通用的maven基础设施，融合了已有的开发流程和工具体系。

图6为本说明书一个或多个实施例提供的一种依赖项目管理工具自定义引用流程的设备的结构示意图，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行：

对模型进行开发产生模型包与代码工程包，所述模型包与所述代码工程包对应；

在模型描述文件中对所述模型包进行模型依赖描述得到模型依赖信息；

在代码工程描述文件中对所述代码工程包进行代码工程依赖描述，得到代码工程依赖信息；

打包和部署所述模型包与所述代码工程包，将所述模型包添加到项目管理工具中，同时推送所述模型包与所述代码工程包；

根据所述模型依赖信息添加所述模型包引用，添加与所述模型包对应的代码工程包引用。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

以上所述仅为本说明书的一个或多个实施例而已，并不用于限制本说明书。对于本领域技术人员来说，本说明书的一个或多个实施例可以有各种更改和变化。凡在本说明书的一个或多个实施例的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本说明书的权利要求范围之内。