Module management methods, devices, electronic equipment, and readable storage media

Abstract

This application discloses a module management method, apparatus, electronic device, and readable storage medium. The method includes: in response to a module management request, obtaining multiple module data of modules included in the module management request; generating a target description file for the module based on the multiple module data; obtaining multiple application data of multiple stored applications; determining at least one target application matching the module among the multiple applications based on the target description file and the multiple application data; obtaining at least one target application identifier of the at least one target application; and authorizing the module to the at least one target application based on the at least one target application identifier. By implementing unified standard management for modules and applications, redundant development and code conflicts are avoided, while ensuring version consistency between modules and applications, improving application development efficiency, and ensuring the stability of module operation.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to a module management method, apparatus, electronic device, and readable storage medium. Background Technology

[0002] With the development of information technology, the applications installed on people's mobile devices are becoming increasingly diverse. However, many different applications share common functionalities. Therefore, in front-end development, reusable modules from other projects are often used. Currently, development teams reuse modules based on code repository levels, using the repository mechanism for manual or automatic code copying and integration. However, manual or automatic code copying and integration is prone to errors, leading to code conflicts and module version management issues, resulting in lower stability of subsequent module operation. Summary of the Invention

[0003] In view of this, this application provides a module management method, apparatus, electronic device, and readable storage medium, the main purpose of which is to solve the technical problem that errors are prone to occur in manual or automatic code copying and integration in the prior art, resulting in low stability of subsequent module operation.

[0004] According to a first aspect of this application, a module management method is provided, the method comprising:

[0005] In response to a module management request, retrieve multiple module data for the modules included in the module management request;

[0006] Generate the target description file for the module based on data from multiple modules;

[0007] Retrieve multiple application data from multiple stored applications;

[0008] Based on the target description file and multiple application data, identify at least one target application that matches the module among multiple applications;

[0009] Obtain at least one target application identifier for at least one target application;

[0010] Based on at least one target application identifier, the module authorizes at least one target application.

[0011] Optionally, the multiple module data includes module identifiers. The step of generating a target description file for a module based on the multiple module data specifically includes:

[0012] Obtain multiple identity identifiers from multiple storage modules;

[0013] Determine whether a module identifier is included among multiple identity identifiers;

[0014] If multiple identity identifiers contain module identifiers, the module is determined to be a stored module.

[0015] Retrieve data from multiple files in the description file corresponding to the module;

[0016] Generate a target description file based on data from multiple modules and multiple files;

[0017] If none of the multiple identity identifiers contain a module identifier, the module is determined to be an unstored module.

[0018] A target description file is generated based on data from multiple modules.

[0019] Optionally, the step of generating a target description file based on multiple module data and multiple file data specifically includes:

[0020] Retrieve multiple data types from multiple modules;

[0021] Based on multiple data types, identify multiple target file data corresponding to multiple module data in multiple file data;

[0022] Based on data from multiple modules, the data in multiple target files is replaced to generate a target description file.

[0023] Optionally, if none of the multiple identity identifiers contain a module identifier, after determining that the module is an unstored module, the following steps are also included:

[0024] Register the modules based on data from multiple modules;

[0025] The registered modules are reviewed based on data from multiple modules and preset review rules.

[0026] If a module passes the review, its identity will be determined based on its module identifier.

[0027] If a module fails the review, retrieve the non-compliant data for that module.

[0028] Based on the non-compliant data, generate a message indicating that the review has failed.

[0029] Send a notification message to the target terminal.

[0030] Optionally, the step of determining at least one target application that matches the module among multiple applications, based on the target description file and multiple application data, specifically includes:

[0031] Based on the preset data names, multiple target data are determined in the target description file;

[0032] The system compares multiple target data sets and multiple application data sets to generate a comparison result showing whether each application meets the module authorization conditions.

[0033] Based on the comparison results, at least one target application is identified among multiple applications.

[0034] Optionally, the step of comparing multiple target data and multiple application data to generate a comparison result of whether each application meets the module authorization conditions specifically includes:

[0035] For any application, if each target data is identical to application data with the same data name, then the application is deemed to meet the module's authorization conditions.

[0036] If any target data is different from application data with the same data name, it is determined that the application does not meet the module's authorization conditions.

[0037] Optionally, based on the comparison results, the step of determining at least one target application among multiple applications specifically includes:

[0038] Based on the comparison results, a list of applications that meet the module authorization conditions is generated;

[0039] Generate an application selection request based on the application list;

[0040] Send the application selection request to the target terminal;

[0041] Receive the selection result sent by the target terminal;

[0042] Based on the selection results, at least one target application is identified.

[0043] According to a second aspect of this application, a module management device is provided, the device comprising:

[0044] The first acquisition module is used to respond to a module management request and acquire multiple module data of the modules included in the module management request;

[0045] The generation module is used to generate the target description file of the module based on data from multiple modules;

[0046] The second acquisition module is used to acquire multiple application data from multiple stored applications;

[0047] The determination module is used to determine at least one target application that matches the module among multiple applications, based on the target description file and multiple application data.

[0048] The third acquisition module is used to acquire at least one target application identifier of at least one target application;

[0049] The authorization module is used to authorize at least one target application based on at least one target application identifier.

[0050] According to a third aspect of this application, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods in the first aspect.

[0051] According to a fourth aspect of this application, a readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0052] By employing the above technical solution, this application provides a module management method, apparatus, electronic device, and readable storage medium. After acquiring multiple module data from uploaded modules, a target description file for the module is established based on this data. Subsequently, the file data within the target description file is matched with application data from all applications within the system to filter out a list of applications meeting the module's criteria. Developers then determine at least one authorized target application from this list, and the module's authorization management for at least one target application is completed through at least one target application identifier. Compared to existing technologies that rely on code repository-level module reuse or assign dedicated personnel to manage module distribution, this application establishes a module management system that implements unified standard management for modules and applications. Based on version-related data of modules and applications, it matches at least one target application with the same version as the module, ensuring that each target application meets the module's authorization criteria. This achieves automated authorization management of modules for applications, avoiding redundant development and code conflicts while ensuring version consistency between modules and applications, effectively solving the module version management problem. It improves application development efficiency while ensuring the stability of module operation.

[0053] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0054] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0055] Figure 1 A schematic diagram of a module management method provided in an embodiment of this application is shown;

[0056] Figure 2A schematic diagram of another module management method provided in an embodiment of this application is shown;

[0057] Figure 3 This illustration shows a schematic diagram of the module registration page provided in an embodiment of this application;

[0058] Figure 4 This illustration shows a schematic diagram of an application registration page provided in an embodiment of this application;

[0059] Figure 5 A schematic diagram of the structure of a module management device provided in an embodiment of this application is shown. Detailed Implementation

[0060] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0061] This application provides a module management method, such as... Figure 1 As shown, the method includes:

[0062] S101. In response to the module management request, obtain multiple module data of the modules included in the module management request.

[0063] This application provides a module management method applicable to the server side, such as a module management system. Specifically, the module management system is used for the management of native applications and native modules. A native application refers to an application written in native development languages ​​such as Java and Objective-C, developed and released based on a mobile native development platform, and running on a mobile operating system. A native application consists of multiple native modules. A native module refers to a functional module written in a native development language, developed based on a mobile native development platform, and running within a native application to achieve a specific function or requirement. Examples include: a car insurance policy issuance module, a policy inquiry module, and an image upload module. To improve software development efficiency and reduce development costs, native modules with the same function in different applications can be reused.

[0064] In practical applications, with the rapid development of mobile internet technology and the increasing penetration rate of smart terminals, various mobile development technologies have emerged. As user demands for mobile applications become more diverse, mobile applications suitable for various business scenarios have been developed, each typically maintained by a different development team. With continuous business development, the number of common and cross-functional modules among applications is increasing. Existing technologies generally employ two solutions to address the reuse of these modules. The first is that development teams reuse modules based on code repository levels, using the code repository mechanism for manual or automatic code copying and integration. However, maintaining and managing code repositories requires significant time and effort; manual or automatic code copying and integration are prone to errors, code conflicts, and module version management issues; furthermore, code repository permissions are difficult to control, posing a risk of code leakage. The second approach involves development teams directly using integration tools such as Cocoapods, Maven, and Gradle for module distribution and management, with each team assigning dedicated personnel to deploy and maintain these tools, as well as release and manage functional modules. However, this approach suffers from overly complex configuration and deployment of integration management tools, cumbersome integration and release processes, low automation, and high maintenance costs. Furthermore, to address compatibility issues between different integration tools, unnecessary dependencies need to be introduced, leading to increased application size and impacting performance. Based on these problems, this application proposes a unified management system for native modules of different applications, implementing a unified standard, standardizing and simplifying the module upload process, automating the module integration process, and establishing module-to-application authorization management. This avoids redundant development and code conflicts, reduces maintenance costs, and ensures code security.

[0065] Specifically, after receiving a module management request, the module management system retrieves multiple module data points for the module included in the request. This module is the native module, and its multiple module data points include: module name, module description, usage instructions, version number, module platform (e.g., Android or iOS mobile operating system), minimum supported platform version (e.g., Android 9.0, iOS 10.1), team name, team contact information, and module package address.

[0066] S102. Generate the target description file of the module based on data from multiple modules.

[0067] In this step, the description file contains the module data for each module. This description file, in conjunction with the module integration engine, is used for subsequent module distribution. Specifically, after acquiring the module data for multiple modules, the data is organized and summarized according to the data format in the description file, thereby generating the module's description file to achieve unified management of the modules.

[0068] S103. Obtain multiple application data from multiple stored applications.

[0069] S104. Based on the target description file and multiple application data, identify at least one target application that matches the module among multiple applications.

[0070] In steps S103 and S104, the module management system can also perform application authorization management for modules. After completing module registration, it establishes authorization operations for modules to applications to achieve module reuse. Specifically, after obtaining multiple application data for each application in the system, it matches the module data in the target description file with the application data of each application, and then filters out a list of applications that meet the conditions for integrating the module from multiple applications. Subsequently, the developers select at least one target application from the application list, and then complete the authorization management for the module to at least one target application by selecting and saving.

[0071] S105. Obtain at least one target application identifier of at least one target application.

[0072] S106. Authorize at least one target application based on at least one target application identifier.

[0073] In steps S105 and S106, after determining at least one target application that meets the conditions for integrating the module, the module completes the authorization management of each target application using the target application identifier of each target application, so as to realize the relevant configuration of the module on the server side.

[0074] The module management method provided in this application involves acquiring multiple module data sets of an uploaded module and then creating a target description file for that module based on this data. Subsequently, the file data within the target description file is matched with application data from all applications within the system to filter out a list of applications that meet the module's criteria. Developers then determine at least one authorized target application from this list, and the module's authorization management for at least one target application is completed using at least one target application identifier. Compared to existing technologies that rely on code repository-level module reuse or assign dedicated personnel to manage module distribution, this application establishes a module management system that implements unified standard management for modules and applications. Based on version-related data of modules and applications, it matches at least one target application with the same version as the module, ensuring that each target application meets the module's authorization criteria. This achieves automated authorization management of modules for applications, avoiding redundant development and code conflicts while ensuring version consistency between modules and applications, effectively solving module version management problems. This improves application development efficiency while ensuring module operational stability.

[0075] Furthermore, as a refinement and extension of the specific implementation methods of the above embodiments, and in order to fully illustrate the specific implementation process of this embodiment, this application provides another module management method, such as... Figure 2 As shown, the method includes:

[0076] S201. In response to the module management request, obtain multiple module data of the modules included in the module management request.

[0077] In this step, after receiving a module management request, the module management system retrieves multiple module data points for the module included in the request. This module is the native module, and its data points include the module name, module description, usage instructions, version number, module platform (e.g., Android or iOS mobile operating system), minimum supported platform version (e.g., Android 9.0, iOS 10.1), team name, team contact information, and module package address.

[0078] In practical applications, after a development team completes the development of a new module and passes testing and acceptance, the relevant code files, resource files, and configuration files are packaged into a module package. Android platform module packages are uniformly packaged in aar (Android Archive) format, while iOS platform module packages are uniformly packaged in framework format, and version control is performed using Git (a distributed version control system). Subsequently, the module package is uploaded to a module management system for unified management. Upon receiving the module package, the module management system parses it to obtain a large amount of module data corresponding to the modules contained within.

[0079] S202. Obtain multiple identity identifiers for multiple storage modules.

[0080] S203. Determine whether the multiple identity identifiers include a module identifier. If yes, proceed to step S204; otherwise, proceed to step S206.

[0081] In steps S202 and S203, the module management system manages newly developed modules and updates the versions of existing modules. Each module has a unique identifier (module identifier). When managing a new module, this identifier is retrieved from the module data of the new module as its identity identifier within the system. Therefore, after obtaining the module data of the uploaded module, it is necessary to determine whether the module is a stored module in the system based on the module identifier included in the module data. Specifically, multiple identifiers of multiple stored modules in the system are retrieved, and these identifiers are matched with the module identifier of the uploaded module to determine whether the module identifier is included among the multiple identifiers. Based on the determination result, it is then determined whether the module is stored in the system.

[0082] S204. Obtain multiple file data from the description file corresponding to the module.

[0083] S205. Generate a target description file based on data from multiple modules and multiple files.

[0084] In steps S204 and S205, if it is determined that the module identifier is included in multiple identity identifiers, it is determined that the module is already stored in the system, indicating that the module version in the system needs to be updated. At this time, the module's description file is retrieved from the system, multiple file data within the description file are obtained, and the file data within the description file is updated using the latest multiple module data for that module to generate an updated target description file.

[0085] Optionally, to ensure the accuracy of module data in the system, only version-related data can be updated when updating module data, such as the version number, minimum supported platform version, module package address, and module dependency information. After successful module data update, the updated data is automatically reviewed based on preset review rules. If the review is successful, an updated target description file is generated.

[0086] S206. Register the modules based on data from multiple modules.

[0087] In this step, if the module identifier is not found among multiple identity identifiers, it means that the module is not stored in the system. In this case, multiple module data of the module are entered to register the new module.

[0088] In practical applications, such as Figure 3 The image shows a schematic diagram of the registration page for the module management system. Relevant personnel from the development team enter the module data as required, click "register," and then complete the registration of the new module through the module registration function of the module management system.

[0089] S207. Based on data from multiple modules and preset review rules, review the registered modules.

[0090] S208. Determine whether the module has passed the review. If yes, proceed to step S209; otherwise, proceed to step S210.

[0091] In steps S207 and S208, to ensure the accuracy of subsequent automatic application packaging, the module management system pre-sets review rules and uses these rules to review the module data of newly registered modules.

[0092] Optionally, preset review rules include code rules and version ranges. Specifically, code rules are used to review the module's code in the code repository to determine if there is any non-compliant content. Version ranges are used to review the module's version to determine if the module's code is within the specified range, preventing outdated modules from becoming unusable. Furthermore, the correctness of the entered module data is reviewed. This is understandable.

[0093] S209. Determine the module's identity identifier based on the module's module identifier.

[0094] In this step, when a module passes the audit, it means that all the module data is accurate. At this time, the module's identifier (module ID) is used as the module's unique identity in the system.

[0095] S210, Obtain non-compliant data from the module;

[0096] S211. Generate a notification message indicating that the review has failed based on the non-compliant data;

[0097] S212. Send the prompt message to the target terminal.

[0098] In steps S210 to S212, when a module fails the review, it indicates that at least one piece of module data does not comply with the preset review rules, such as the module version being lower than the version range specified in the preset review rules. At this point, the non-compliant data is retrieved, i.e., one or more pieces of module data that do not comply with the preset review rules, and a notification message indicating that the module review has failed is generated based on this non-compliant data. Subsequently, the notification message is sent to the target terminal of the development team's R&D personnel, enabling them to rectify the module data based on the non-compliant data in the notification message, or to suspend the module's authorization management.

[0099] By using the above methods, the module data of the newly registered modules is reviewed, and the developers are notified to modify any non-compliant module data, thereby ensuring the accuracy of the module data in the system and guaranteeing the stability of subsequent application operation.

[0100] S213. Generate a target description file based on data from multiple modules.

[0101] In this step, multiple module data are reviewed to confirm that all data in the module meets the preset review rules and that the entered module data is accurate. Then, the system will automatically create a description file containing the module data for the module. This file, together with the module integration engine, is used for subsequent module authorization and distribution.

[0102] Optionally, the description file includes the module name, module description, usage instructions, version number, module platform, minimum supported platform version, team name, team contact information, template package address, and the module's dependency information. Specifically, the dependency information refers to the module identifiers, module package addresses (i.e., the location of the module's code in the code repository), and version numbers of other modules that the module depends on.

[0103] In practical applications, since modules are independent functional components, as business grows, some complex functions need to be modularized. When any function of a module has been implemented by another module, a dependency arises, requiring other modules to provide support to that module or use its provided functions. Therefore, during the development of complex modules, developers can pre-build dependencies between modules based on multiple modules registered in the system. A module can load another module at runtime to share resources, call functions, or perform other operations. After a complex functional module is registered in the system, one or more modules that the module depends on can be filtered out based on the established dependencies, generating a dependency list. For example, if module A corresponds to functions 1, 2, and 3, the system can be filtered to see if module a (for function 1) and module b (for function 2) are included. Then, dependencies between module A and modules a and b can be built. The dependency information for module A includes the module identifier, package address, and version number of module a, as well as the module identifier, package address, and version number of module b. When using module A subsequently, modules a and b can be called based on the dependency information.

[0104] S214. Obtain multiple application data from multiple stored applications.

[0105] In this step, the module management system can also manage application authorization for modules. After a module is registered, authorization operations between the module and the application are established to enable module reuse. Specifically, multiple application data points for each registered application in the system are obtained. Based on this application data, version information such as the application platform, version number, and minimum supported platform version number is determined. Then, based on the application data and the module's data, a match is made between the module and the application to filter out applications that meet the integration criteria.

[0106] In practical applications, the management team needs to register new applications in the module management system. Specifically, for example... Figure 4The image shows a schematic of the application registration page for the module management system. Developers enter application-related data as required. The application platform can be Android, iOS, or all platforms. If Android is selected, the minimum supported Android version, Android application signature, and Android package name must be entered. If iOS is selected, the minimum supported iOS version and iOS Bundle ID must be entered. If all platforms are selected, all of the above data must be entered. After successful registration, the system uses the application ID (Android package name or iOS Bundle ID; Android package name is used for all platforms) as the application identifier and automatically submits it for review to verify the accuracy of the entered data and whether the version is within the preset range. Only after the review is approved can the module authorize the application.

[0107] S215. Based on the preset data names, determine multiple target data in the target description file.

[0108] S216. Compare multiple target data and multiple application data to generate a comparison result of whether each application meets the module authorization conditions.

[0109] S217. Based on the comparison results, identify at least one target application among the multiple applications.

[0110] In steps S215 to S217, the preset data name refers to the data name of version-related data used for matching between the module and the application. During the matching process, the platform and minimum supported platform version of the module and the application need to be matched. Only when the application's platform and minimum supported platform version are the same as the model's are the applications considered to meet the model's authorization conditions. Therefore, based on the preset data name, multiple version-related target data are filtered out from the module's target description file. Then, target data with the same data name are compared with application data. Based on the comparison result, it is determined whether each application meets the module's authorization conditions. A list of applications that meet the module's authorization conditions is then generated based on the comparison results. Finally, the developers select at least one target application from the application list that can be authorized.

[0111] In this embodiment of the application, optionally, step S216, which compares multiple target data and multiple application data to generate a comparison result of whether each application meets the module's authorization conditions, specifically includes: for any application, if each target data is the same as the application data with the same data name, it is determined that the application meets the module's authorization conditions; if any target data is different from the application data with the same data name, it is determined that the application does not meet the module's authorization conditions.

[0112] In this embodiment, target data with the same data name are mapped one-to-one with application data. Then, the corresponding target data and application data are compared. For any application, if all target data and its corresponding application data are the same, it means that the module's version-related data is the same as the application's version-related data, thus determining that the application meets the module's authorization conditions. If any target data is different from its corresponding application data, it means that there is a difference between the module's version-related data and the application's version-related data, and in this case, it is determined that the application does not meet the module's authorization conditions. Following this method, the application data of each application is compared one-to-one to determine whether each application meets the module's authorization conditions. Based on the comparison results, a list of licensable applications for the module is generated, containing the names of all applications that meet the module's authorization conditions.

[0113] In practical applications, the target description file of a module is used to filter version-related data based on preset data names. This includes the module platform, minimum supported platform version, and dependency information, specifically the module platforms and minimum supported platform versions of dependent modules. The application platforms and minimum supported platform versions of all applications in the system are obtained. The module platform is compared with the application platform of each application to determine if they are the same. Similarly, the minimum supported platform version of the module is compared with the minimum supported platform version of the application to ensure they are the same. Furthermore, the module platforms and minimum supported platform versions of the module's dependent modules are also compared with the application's application platform and minimum supported platform version to ensure that the application meets the authorization conditions of the dependent modules when the module calls them.

[0114] Optionally, in this embodiment, step S217, namely determining at least one target application from among multiple applications based on the comparison results, specifically includes: generating a list of applications that meet the module authorization conditions based on the multiple comparison results; generating an application selection request based on the application list; sending the application selection request to the target terminal; receiving the selection result sent by the target terminal; and determining at least one target application based on the selection result.

[0115] In this embodiment, to ensure the stability and reliability of subsequent module operation, applications with a small user base and limited impact can be pre-authorized for pilot operation of the new module. Once the module is running stably, all applications in the application list will be authorized to integrate the module. Therefore, after generating an application list that meets the module authorization conditions, an application selection request is generated based on this application list and sent to the target terminals of the development team's researchers. This allows the researchers to select at least one target application for pilot operation from the application list displayed in the system. Based on the researchers' selections, at least one target application is then determined for this authorization.

[0116] After determining the list of authorized applications through the above methods, the R&D personnel select a portion of the applications with fewer users and a smaller impact range for pilot release. This allows for the pilot operation of the new module, ensuring the stability of the module's operation and thereby improving the stability and reliability of subsequent application operation.

[0117] S218. Obtain at least one target application identifier of at least one target application.

[0118] S219. Authorize the module to at least one target application based on at least one target application identifier.

[0119] In steps S218 and S219, after determining at least one target application that meets the conditions for integrating the module, the module completes the authorization management of each target application using the target application identifier of each target application, so as to realize the relevant configuration of the module and application on the server side.

[0120] In practical applications, after completing the relevant server-side configurations, the integration script is automatically executed during application packaging. Specifically, after the integration script starts executing, it automatically calls the server-side interface. Upon receiving the request, the server verifies the application's authorization status. If the verification passes, the server returns the application's configuration file according to the module management system configuration. This configuration file contains application data and authorized module data. Upon receiving the configuration file, the integration tool within the application (based on Gradle for Android and Cocoapods for iOS) performs an update verification. If the server-side module configuration is not updated, the application packaging process proceeds directly. If the server-side module configuration is updated, the integration tool parses the configuration file to obtain a list of authorized modules. Based on this list, the integration tool automatically sends a module retrieval request to the server, sequentially pulling the module packages into the application. After successful retrieval, the integration tool performs a series of operations based on the description files in the module packages, including module package parsing, parameter configuration, and dependency setting. After this process is complete, the application has integrated the authorized modules and continues with the application packaging process. Once the application is packaged, the modules are automatically displayed in their respective positions within the application according to the different page layout rules of each application, ultimately completing module distribution. By using the above methods, the entire module integration process is integrated into the application packaging process, and the entire process is executed automatically, which greatly improves development efficiency, reduces maintenance costs, and ensures code security.

[0121] Furthermore, as Figure 1 To specifically implement the method, this application embodiment provides a module management device 300, such as... Figure 5 As shown, the device includes:

[0122] The first acquisition unit 301 is used to acquire multiple module data of the modules included in the module management request in response to the module management request;

[0123] The generation unit 302 is used to generate a target description file for a module based on data from multiple modules;

[0124] The second acquisition unit 303 is used to acquire multiple application data of multiple applications that have been stored;

[0125] The determining unit 304 is used to determine at least one target application that matches the module among multiple applications, based on the target description file and multiple application data.

[0126] The third acquisition unit 305 is used to acquire at least one target application identifier of at least one target application;

[0127] The authorization unit 306 is used to authorize the module to at least one target application based on at least one target application identifier.

[0128] Optionally, the multiple module data includes the module identifier, and the generation unit 302 is specifically used for:

[0129] Obtain multiple identity identifiers from multiple storage modules;

[0130] Determine whether a module identifier is included among multiple identity identifiers;

[0131] If multiple identity identifiers contain module identifiers, the module is determined to be a stored module.

[0132] Retrieve data from multiple files in the description file corresponding to the module;

[0133] Generate a target description file based on data from multiple modules and multiple files;

[0134] If none of the multiple identity identifiers contain a module identifier, the module is determined to be an unstored module.

[0135] A target description file is generated based on data from multiple modules.

[0136] Optionally, the device further includes:

[0137] The fourth acquisition unit 307 is used to acquire multiple data types of data from multiple modules.

[0138] Optionally, the determining unit 304 is also used to determine multiple target file data corresponding to multiple module data in multiple file data according to multiple data types;

[0139] The generation unit 302 is also used to replace multiple target file data based on multiple module data to generate a target description file.

[0140] Optionally, the device further includes:

[0141] Registration unit 308 is used to register modules based on data from multiple modules;

[0142] The review unit 309 is used to review the registered modules based on data from multiple modules and preset review rules.

[0143] Optionally, the determining unit 304 is also used to determine the identity identifier of the module based on the module identifier if the module passes the review.

[0144] Optionally, the device further includes:

[0145] The fifth acquisition unit 310 is used to acquire the non-compliant data of a module if the module fails the review.

[0146] Optionally, the generation unit 302 is also used to generate a prompt message indicating that the audit has failed based on the non-compliant data.

[0147] Optionally, the device further includes:

[0148] The sending unit 311 is used to send the prompt information to the target terminal.

[0149] Optionally, unit 304 is specifically used for:

[0150] Based on the preset data names, multiple target data are determined in the target description file;

[0151] The system compares multiple target data sets and multiple application data sets to generate a comparison result showing whether each application meets the module authorization conditions.

[0152] Based on the comparison results, at least one target application is identified among multiple applications.

[0153] Optionally, unit 304 is further used for:

[0154] For any application, if each target data is identical to application data with the same data name, then the application is deemed to meet the module's authorization conditions.

[0155] If any target data is different from application data with the same data name, it is determined that the application does not meet the module's authorization conditions.

[0156] Optionally, the generation unit 302 is also used to generate a list of applications that meet the module authorization conditions based on the comparison results;

[0157] The generation unit 302 is also used to generate an application selection request based on the application list;

[0158] The sending unit 311 is also used to send the application selection request to the target terminal.

[0159] Optionally, the device further includes:

[0160] The receiving unit 312 is used to receive the selection result sent by the target terminal.

[0161] Optionally, the determining unit 304 is also configured to determine at least one target application based on the selection result.

[0162] The module management device 300 provided in this application embodiment acquires multiple module data of uploaded modules and establishes a target description file for the module based on the multiple module data. Subsequently, it matches the file data within the target description file with the application data of all applications in the system to filter out a list of applications that meet the module's conditions from multiple applications. Then, developers determine at least one target application that can be authorized from the application list, and the authorization management of the module for at least one target application is completed through at least one target application identifier of at least one target application. Compared to the prior art, which uses code repository-level module reuse or assigns dedicated personnel to manage module distribution in each team, this application establishes a module management system that implements unified standard management for modules and applications. Based on the version-related data of modules and applications, it matches at least one target application with the same version as the module, ensuring that each target application meets the module authorization conditions. This achieves automated authorization management of modules for applications, avoiding redundant development and code conflicts while ensuring version consistency between modules and applications, effectively solving the module version management problem. It improves application development efficiency while ensuring the stability of module operation.

[0163] In an exemplary embodiment, this application also provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor executes the program stored in the memory to perform the module management method described in the above embodiments.

[0164] In an exemplary embodiment, this application also provides a readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the module management method.

[0165] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented in hardware or by using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) and includes several instructions to cause an electronic device (such as a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0166] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0167] Those skilled in the art will understand that the modules in the apparatus of the implementation scenario can be distributed within the apparatus of the implementation scenario as described, or they can be located in one or more apparatuses different from this implementation scenario, with corresponding changes. The modules of the above-described implementation scenario can be combined into one module, or they can be further divided into multiple sub-modules.

[0168] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of the implementation scenario.

[0169] The above disclosures are only a few specific implementation scenarios of this application. However, this application is not limited to these. Any variations that can be conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A module management method, characterized in that, include: In response to a module management request, obtain multiple module data of the modules included in the module management request; Based on the data from the multiple modules, generate the target description file for each module; Retrieve multiple application data from multiple stored applications; Based on the target description file and multiple application data, at least one target application that matches the module is identified among the multiple applications; Obtain at least one target application identifier of the at least one target application; Based on the at least one target application identifier, the module authorizes the at least one target application; The step of determining at least one target application that matches the module among the multiple applications based on the target description file and multiple application data specifically includes: According to the preset data name, multiple target data are determined in the target description file. The preset data name is the data name of the version-related data for matching between the module and the application. The version-related data includes: module platform, minimum supported platform version, and the module platform and minimum supported platform version of the dependent module in the module's dependency information. The multiple target data and the multiple application data are compared to generate a comparison result of whether each application meets the module authorization conditions; Based on the comparison results, at least one target application is determined from the plurality of applications; The step of comparing the plurality of target data and the plurality of application data to generate a comparison result of whether each application meets the module authorization conditions specifically includes: Obtain the application platform and minimum supported platform version of all applications in the system, and compare the module platform of the module with the application platform of each application. Compare the module's minimum supported platform version with the application's minimum supported platform version; The module platforms and minimum supported platform versions of the modules that depend on this module are also compared with the application platform and minimum supported platform version of the application. For any application, if each target data is identical to application data with the same data name, then the application is deemed to meet the module's authorization conditions. If any target data is different from application data with the same data name, it is determined that the application does not meet the module's authorization conditions.

2. The method according to claim 1, characterized in that, The plurality of module data includes the module identifier of the module, and the step of generating the target description file of the module based on the plurality of module data specifically includes: Obtain multiple identity identifiers from multiple storage modules; Determine whether the module identifier is included among the multiple identity identifiers; If the module identifier is included in the plurality of identity identifiers, the module is determined to be a stored module; Obtain multiple file data of the description file corresponding to the module; The target description file is generated based on the multiple module data and the multiple file data; If the module identifier is not included among the multiple identity identifiers, the module is determined to be an unstored module; The target description file is generated based on the data from the multiple modules.

3. The method according to claim 2, characterized in that, The step of generating the target description file based on the multiple module data and the multiple file data specifically includes: Obtain multiple data types of data from the multiple modules; Based on the multiple data types, multiple target file data corresponding to the multiple module data are determined from the multiple file data; Based on the data from the multiple modules, the data from the multiple target files are replaced to generate the target description file.

4. The method according to claim 2, characterized in that, If the module identifier is not included among the multiple identity identifiers, after determining that the module is an unstored module, the method further includes: The modules are registered based on the data from the multiple modules; The registered modules are reviewed based on the data from the multiple modules and the preset review rules. If the module passes the review, the module's identity identifier is determined based on the module's identifier. If the module fails the review, obtain the non-compliant data for the module; Based on the non-compliant data, a notification message indicating that the review has failed is generated; The prompt message is sent to the target terminal.

5. The method according to claim 1, characterized in that, The step of determining the at least one target application among the plurality of applications based on the comparison results specifically includes: Based on the comparison results, a list of applications that meet the module authorization conditions is generated; Based on the application list, generate an application selection request; Send the application selection request to the target terminal; Receive the selection result sent by the target terminal; Based on the selection results, at least one target application is determined.

6. A module management device, characterized in that, include: The first acquisition unit is used to acquire multiple module data of the modules included in the module management request in response to the module management request; A generation unit is configured to generate a target description file for the module based on the plurality of module data; The second acquisition unit is used to acquire multiple application data from multiple stored applications; The determining unit is configured to determine, based on the target description file and multiple application data, at least one target application that the module matches among the multiple applications; The third acquisition unit is used to acquire at least one target application identifier of the at least one target application; An authorization unit is configured to authorize the module to access the at least one target application based on the at least one target application identifier. Determine the unit, specifically for: According to the preset data name, multiple target data are determined in the target description file. The preset data name is the data name of the version-related data for matching between the module and the application. The version-related data includes: module platform, minimum supported platform version, and the module platform and minimum supported platform version of the dependent module in the module's dependency information. The multiple target data and the multiple application data are compared to generate a comparison result of whether each application meets the module authorization conditions; Based on the comparison results, at least one target application is determined from the plurality of applications; Determining the unit, specifically also used for: Obtain the application platform and minimum supported platform version of all applications in the system, and compare the module platform of the module with the application platform of each application. Compare the module's minimum supported platform version with the application's minimum supported platform version; The module platforms and minimum supported platform versions of the modules that depend on this module are also compared with the application platform and minimum supported platform version of the application. For any application, if each target data is identical to application data with the same data name, then the application is deemed to meet the module's authorization conditions. If any target data is different from application data with the same data name, it is determined that the application does not meet the module's authorization conditions.

7. An electronic device comprising a memory and a processor, the memory storing a computer program, characterized in that, When a processor executes a computer program, it implements the steps of the method described in any one of claims 1 to 5.

8. A readable storage medium having a computer program stored thereon, characterized in that, When a computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 5.

Images