CN117075956A - 一种应用于模块化项目的配置插拔方法和系统 - Google Patents

Abstract

本申请公开了一种应用于模块化项目的配置插拔方法和系统，其中方法包括：在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别模块化项目中各模块间的依赖关系，构建依赖树；将各模块中需要聚合的配置文件，按照各模块间的依赖关系的依赖顺序给配置文件命名，获得配置文件的配置文件名；在Maven插件执行package、install时，扫描依赖树；根据依赖树的依赖顺序和配置文件名的规律，依次提取各模块中对应的配置文件；遵循依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件；覆盖完成后生成新的配置文件，对新的配置文件重新命名，并进行合并打包。

Description

一种应用于模块化项目的配置插拔方法和系统

技术领域

本申请涉及模块化项目的配置管理领域，具体而言，涉及一种应用于模块化项目的配置插拔方法和系统。

背景技术

Spring框架基于Java语言和面向对象的编程思想，将多个技术和框架整合到一个框架中，提供了一套简单易用的开发模型，能够提高开发效率、降低维护成本，并且能够提高应用程序的可测试性和可扩展性。

Spring框架的另一个特点是其高度模块化的特性。可以选择使用整个Spring框架或仅使用必要的模块。此外，可以根据需要选择包含一个或多个Spring项目。但随着模块化在软件项目中的广泛应用，在插拔场景下会出现配置冗余和配置集成困难等问题。这些问题会给开发人员和系统管理员带来额外的工作负担，并可能导致错误和不一致性。现有技术中，使用spring.profile.include命令来指定要包含的配置文件。然而，include命令的先后顺序需要严格校验，它并不会自动遵循依赖树结构。因此，在模块化项目组合形式发生变化时，需要手动调整该配置。

发明内容

为了解决上述技术问题，本申请提供一种应用于模块化项目的配置插拔方法和系统，通过合理配置项目的依赖关系、使用模块化开发工具和定义命名规范，有效地减少插拔场景下的配置集成困难和冗余问题。

具体的，本申请的技术方案如下：

第一方面，本申请公开一种应用于模块化项目的配置插拔方法，包括如下步骤：

在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树；

将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名；

在所述Maven插件执行package操作或install操作时，遍历所述依赖树；

根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件；

遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件；覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

在一些实施方式中，所述的获得所述配置文件的配置文件名之后，还包括如下步骤：

使用通配符匹配规则加载所述配置文件；以便将所述配置文件自动排序；

若所述模块化项目中各所述模块的组合形式发生变化，所述配置文件名随之更新。

在一些实施方式中，所述的自动识别所述模块化项目中各模块间的依赖关系，之前还包括如下步骤：

使用自定义的配置规范，约束所述配置文件的命名规律；

使用自定义的配置规范，约束各所述模块的结构和格式。

第二方面，本申请公开一种应用于模块化项目的配置插拔系统，其特征在于，包括：

构建单元，用于在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树；

命名单元，用于将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名；

扫描单元，用于在所述Maven插件执行package操作或install操作时，遍历所述依赖树；

提取模块，用于根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件；

合并单元，用于遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件；覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

在一些实施方式中，所述命名单元，还用于：使用通配符匹配规则加载所述配置文件；以便将所述配置文件自动排序；

所述命名单元，还用于：若所述模块化项目中各所述模块的组合形式发生变化在一些实施方式中，还包括：配置单元，用于使用自定义的配置规范，约束所述配置文件的命名规律；还用于使用自定义的配置规范，约束各所述模块的结构和格式。

与现有技术相比，本申请至少具有以下一项有益效果：

1、本申请可以根据项目的依赖关系自动加载配置文件，并根据自定义的配置规范，自动将配置拆分为独立的模块配置。这样，当需要组合模块时，只需引入相应的模块配置即可，避免了手动复制粘贴配置的冗余操作。本申请在Spring Boot自动配置机制的基础上，使用模块化开发工具Maven插件，可以自动处理依赖关系的加载顺序。通过合理的定义和管理模块的依赖关系。可以简化配置的管理和集成过程。Maven插件可以自动识别并处理模块间的依赖关系，并确保正确的加载和合并各模块的配置。

2、为了简化配置文件的管理，本申请可以采用一套自定义的命名规范来组织配置文件，例如，按照模块的依赖顺序给配置文件命名，本申请中该规范包括配置文件的命名约定、配置项的结构和格式等要求。可以使配置的拆分与聚合更加规范和统一，以确保各个模块的配置能够正确地被解析和处理。

附图说明

下面将以明确易懂的方式，结合附图说明优选实施方式，对本申请的上述特性、技术特征、优点及其实现方式予以进一步说明。

图1为本申请一个方法实施例的步骤流程图；

图2本申请一个系统实施例的结构框图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本申请实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其他实施例中也可以实现本申请。在其他情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

应当理解，当在本说明书和所附权利要求书中使用时，术语“包括”指示所述描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其他特征、整体、步骤、操作、元素、组件和/或集合的存在或添加。

为使图面简洁，各图中只示意性地表示出了与发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘示了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。

还应当进一步理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

在本文中，需要说明的是，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体的连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内部的连通。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。

具体实现中，本申请实施例中描述的终端设备包括但不限于诸如具有触摸敏感表面(例如，触摸屏显示器和/或触摸板)的移动电话、膝上型计算机、家教机或平板计算机之类的其他便携式设备。还应当理解的是，在某些实施例中，所述终端设备并非便携式通信设备，而是具有触摸敏感表面(例如：触摸屏显示器和/或触摸板)的台式计算机。

另外，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对照附图说明本申请的具体实施方式。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。

参考说明书附图1，本申请提供的一种应用于模块化项目的配置插拔方法的一个实施例，包括如下步骤：

S100，在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树。

S200，将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名。

S300，在所述Maven插件执行package操作或install操作时，遍历所述依赖树。

S400，根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件。

S500，遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件。覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

具体的，本申请为了优化现有技术中存在问题，做出了以下几点优化：

1、使用Spring Boot的自动配置机制：具体的，Spring框架基于Java语言和面向对象的编程思想，将多个技术和框架整合到一个Spring Boot框架中，在构建Spring应用时，只需要添加相应的场景依赖，Spring Boot就会根据添加的场景依赖自动进行配置，在无须额外手动添加配置的情况下构建出一个独立的Spring应用。Spring Boot提供了自动配置机制，可以根据项目的依赖关系自动加载配置文件。通过正确地配置各个模块之间的依赖关系，可以让Spring Boot自动按照依赖树结构加载配置文件，从而避免手动调整spring.profile.include的先后顺序。

2、使用模块化开发工具：在项目采用模块化的开发方式时，使用现代化的构建工具插件，如Maven插件或Gradle插件。这些工具支持定义模块之间的依赖关系，并可以自动处理依赖关系的加载顺序。通过合理的定义和管理模块的依赖关系，可以减少手动调整spring.profile.include的需求。具体的，Maven是一个开源的项目管理和构建工具，可以帮助执行自动化构建、依赖管理和项目部署等任务。而Maven插件则是通过扩展Maven的功能，为项目提供额外的构建、测试、部署和其他任务的支持。Maven插件可以由开发者编写，并且可以在项目的pom.xml文件中声明和配置。在Maven生命周期的各个阶段，插件会被调用执行特定的任务，如编译compiler、测试surefire、文件安装install、压缩打包package等。通过使用Maven插件，可以扩展和定制Maven的功能，满足项目的特定需求。

3、配置文件的命名规范：为了简化配置文件的管理，本申请采用一套命名规范来组织配置文件。例如，可以按照模块的依赖顺序给配置文件命名，然后在spring.profile.include中使用通配符匹配规则来加载配置文件。这样可以避免手动调整spring.profile.include的先后顺序，而只需根据模块化项目组合形式的变化来更新配置文件的命名。具体的，将模块中需要聚合的配置文件，统一命名为application-self.yml。将聚合后生成新的配置文件统一命名为application.yml，并置于打包项目中。

综上，本申请实施例通过合理配置项目的依赖关系、使用模块化开发工具和定义命名规范，可以优化spring.profile.include的使用方式，避免手动调整配置的麻烦，并保持配置与项目组合形式的同步。

上述实施例中，所述的步骤S200，获得所述配置文件的配置文件名之后，还包括如下步骤：

S210，使用通配符匹配规则加载所述配置文件。以便将所述配置文件自动排序。具体的，通配符是一种特殊语句，主要有星号和问号，用来模糊搜索文件。当查找文件夹时，可以使用它来代替一个或多个真正字符；在实际应用中，当不知道真正字符或者不能输入完整名字时，可以根据设计者需求使用通配符代替一个或多个真正的字符。

S220，若所述模块化项目中各所述模块的组合形式发生变化，所述配置文件名随之更新。

本实施例的另一实施方式中，所述的自动识别所述模块化项目中各模块间的依赖关系，之前还包括如下步骤：

S010，使用自定义的配置规范，约束所述配置文件的命名规律。使用自定义的配置规范，约束各所述模块的结构和格式。

具体的，模块中需要聚合的配置文件，统一命名为application-self.yml。application.yml是一种常用的配置文件格式，它使用YAML(YAML Ain't MarkupLanguage)语法来表示配置信息。相比于使用文件，提供了更加简洁和易读的配置方式。application-self.yml在application.yml的基础上增加的自定义的命名成分。

基于相同构思，如说明书附图2所示，本申请还公开一种应用于模块化项目的配置插拔系统，其特征在于，所述系统通过执行上述任一方法实施例来实现模块化项目的配置插拔，包括：

构建单元10，用于在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树。

命名单元20，用于将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名。

扫描单元30，用于在所述Maven插件执行package操作或install操作时，遍历所述依赖树。

提取模块40，用于根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件。

合并单元50，用于遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件。覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

具体的，扫描单元30、提取模块40、合并单元50，用于在Maven插件执行压缩打包(Maven生命周期package)和打包文件的具体安装(Maven生命周期install)时，会将模块项目中的配置按照如下流程图，进行聚合。

S1：扫描构建项目的依赖树。

S2：根据依赖树和规范的配置文件名，按层次提取依赖模块项目中的配置文件。

S3：遵循由远及近的原则聚合配置，对于同一配置项，近的覆盖远的。

S4：生成新的配置文件application.yml，并警于打包项目中。

更优的，依赖树的聚合复用原则是软件工程中的一个设计原则，它指导着设计者如何组织和管理软件模块之间的依赖关系，以实现高内聚、低耦合的目标。根据该原则，模块应该通过聚合关系进行复用，而不是直接依赖具体的实现类。简单来说，一个模块应该依赖于其所需要的功能接口或抽象类，而不是依赖于具体的实现类。这样做可以提高代码的灵活性和可维护性，同时降低了模块之间的耦合度。通过聚合关系进行复用可以将模块解耦，使得模块之间的依赖关系更加清晰和可控。当需要替换或升级某个模块时，只需要提供新的实现类并实现相同的接口或继承相同的抽象类即可，而不会对其他模块产生影响。这种设计思想也促进了代码的可测试性，因为可以通过依赖注入等技术来模拟或替换依赖的模块，方便进行单元测试和集成测试。

综上，本系统实施例具有以下几项有益效果：

1、自适应模块化项目的插拔：本系统可以轻松应对各种模块化项目组合场景。不论是增加、替换或删除模块，本系统都能够自动适应并确保系统的正常运行。

2、减少配置聚合的人工参与：本系统通过自动化的配置聚合过程，减少了人工参与的需要。这样可以节省时间和资源，并降低因人为疏忽导致的错误风险。

3、避免不必要的问题：由于本系统的自适应性和自动化特性，可以避免因人为疏忽而引起的不必要的问题。本系统能够在插拔模块时自动进行任务分配和配置调整，确保系统的稳定性和一致性。

本实施例的另一实施方式中，所述命名单元20，还用于：使用通配符匹配规则加载所述配置文件。以便将所述配置文件自动排序。还用于：若所述模块化项目中各所述模块的组合形式发生变化，所述配置文件名随之更新。

本实施例的另一实施方式中，上述一种应用于模块化项目的配置插拔系统还包括：配置单元60，用于在执行方法步骤之前，使用自定义的配置规范，约束所述配置文件的命名规律。还用于使用自定义的配置规范，约束各所述模块的结构和格式。

本申请的一种应用于模块化项目的配置插拔方法和系统具有相同的技术构思，二者的实施例的技术细节可相互适用，为减少重复，此次不再赘述。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各程序模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的程序模块完成，即将所述系统的内部结构划分成不同的程序单元或模块，以完成以上描述的全部或者部分功能。实施例中的各程序模块可以集成在一个处理单元中，也可是各个单元单独物理存在，也可以两个或两个以上单元集成在一个处理单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件程序单元的形式实现。另外，各程序模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详细描述或记载的部分，可以参见其他实施例的相关描述。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件，或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

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

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

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。

Claims (6)

1.一种应用于模块化项目的配置插拔方法，其特征在于，包括如下步骤：

在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树；

将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名；

在所述Maven插件执行package操作或install操作时，扫描所述依赖树遍历所述依赖树；

根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件；

遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件；覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

2.如权利要求1所述的一种应用于模块化项目的配置插拔方法，其特征在于，所述的获得所述配置文件的配置文件名之后，还包括如下步骤：

使用通配符匹配规则加载所述配置文件；以便将所述配置文件自动排序；

若所述模块化项目中各所述模块的组合形式发生变化，所述配置文件名随之更新。

3.如权利要求1所述的一种应用于模块化项目的配置插拔方法，其特征在于，所述的自动识别所述模块化项目中各模块间的依赖关系，之前还包括如下步骤：

使用自定义的配置规范，约束所述配置文件的命名规律；

使用自定义的配置规范，约束各所述模块的结构和格式。

4.一种应用于模块化项目的配置插拔系统，其特征在于，包括：

构建单元，用于在Spring Boot自动配置机制的基础上，通过Maven插件，自动识别所述模块化项目中各模块间的依赖关系，构建依赖树；

命名单元，用于将各所述模块中需要聚合的配置文件，按照各所述模块间的所述依赖关系的依赖顺序给所述配置文件命名，获得所述配置文件的配置文件名；

扫描单元，用于在所述Maven插件执行package操作或install操作时，遍历所述依赖树；

提取模块，用于根据所述依赖树的所述依赖顺序和所述配置文件名的规律，依次提取各所述模块中对应的所述配置文件；

合并单元，用于遵循所述依赖树的聚合复用原则，对于不同模块中的多个所述配置文件，依照依赖树的层级关系，由顶层配置文件覆盖深层的配置文件；覆盖完成后生成新的配置文件，对所述新的配置文件重新命名，并进行合并打包。

5.如权利要求4所述的一种应用于模块化项目的配置插拔系统，其特征在于，所述命名单元，还用于：使用通配符匹配规则加载所述配置文件；以便将所述配置文件自动排序；

所述命名单元，还用于：若所述模块化项目中各所述模块的组合形式发生变化，所述配置文件名随之更新。

6.如权利要求4所述的一种应用于模块化项目的配置插拔系统，其特征在于，还包括：配置单元，用于使用自定义的配置规范，约束所述配置文件的命名规律；还用于使用自定义的配置规范，约束各所述模块的结构和格式。