A driving management method, device, apparatus and medium

Abstract

The application discloses a drive management method and device, equipment and medium, to realize perfect drive management, and relates to the technical field of resource management. The method specifically comprises the following steps: connecting a Nexus warehouse through a Nexus warehouse manager; and performing at least one of drive management, drive package management or drive version management through a Maven component, a Spring Boot framework and the Nexus warehouse, so that the technical boundary of Maven is expanded, efficient management of drives, drive packages or drive versions is realized by relying on the Nexus warehouse.

Description

Technical Field

[0001] This invention relates to the field of resource management technology, and in particular to a drive management method, apparatus, equipment and medium. Background Technology

[0002] Existing banking systems typically accumulate a large number of peripheral drivers. With the increasing localization of technology and the export of drivers from other banks, the number of drivers is growing, and driver versions are becoming increasingly difficult to manage. Currently, employee-channel peripherals are simply placed in a few directories without any refined management measures for specific vendor drivers.

[0003] In existing technologies, Maven is typically used to manage driver files. However, Maven can only be used to manage dependencies in Java projects and has insufficient ability to manage dependencies in other projects, thus failing to achieve fine-grained driver management. Summary of the Invention

[0004] This invention provides a drive management method, apparatus, device, and medium for achieving comprehensive drive management.

[0005] In a first aspect, the present invention provides a driver management method, the method comprising: connecting to a Nexus repository through a Nexus repository manager; and performing at least one of driver management, driver package management, or driver version management through a Maven component, a Spring Boot framework, and a Nexus repository.

[0006] In one possible design, it also includes: obtaining driver information; performing at least one of driver management, driver package management, or driver version management, including: performing driver management based on the driver information.

[0007] In one possible design, driver management is performed based on driver information, including storing driver information in a Nexus repository.

[0008] In one possible design, the driver information includes at least one of the following: the driver group to which the driver belongs, the driver name, the driver version number, or the dependency information between the driver and other drivers.

[0009] In one possible design, it also includes: obtaining information about the driver package, which includes multiple drivers belonging to the same driver group; and managing the driver package based on the information about the driver package.

[0010] In one possible design, driver package management is performed based on driver package information, including storing driver package information in a Nexus repository.

[0011] In one possible design, the driver package information is used to indicate at least one of the following: the legal entity to which multiple drivers belong, the name of multiple drivers, or the version number of multiple drivers.

[0012] In one possible design, it also includes: obtaining the version number; and managing the version number of at least one driver and / or at least one driver package.

[0013] In one possible design, version number management is performed on at least one driver and / or at least one driver package based on the version number, including: moving at least one driver and / or at least one driver package to a directory of a specified Nexus repository based on the version number.

[0014] Secondly, the present invention also provides a drive management device, the device comprising:

[0015] Create a module to connect to the Nexus repository via the Nexus repository manager;

[0016] The management module is used to perform at least one of driver management, driver package management, or driver version management through Maven components, the Spring Boot framework, and the Nexus repository.

[0017] In one possible design, the management module is also used to: obtain driver information; perform at least one of driver management, driver package management, or driver version management, including: performing driver management based on the driver information.

[0018] In one possible design, driver management is performed based on driver information, including storing driver information in a Nexus repository.

[0019] In one possible design, the driver information includes at least one of the following: the driver group to which the driver belongs, the driver name, the driver version number, or the dependency information between the driver and other drivers.

[0020] In one possible design, the management module is also used to: obtain information about driver packages, which include multiple drivers belonging to the same driver group; and manage driver packages based on the information about the driver packages.

[0021] In one possible design, driver package management is performed based on driver package information. The management module is also used to store driver package information in the Nexus repository.

[0022] In one possible design, the driver package information is used to indicate at least one of the following: the legal entity to which multiple drivers belong, the name of multiple drivers, or the version number of multiple drivers.

[0023] In one possible design, the management module is also used to: obtain the version number; and manage the version number of at least one driver and / or at least one driver package.

[0024] In one possible design, version number management is performed on at least one driver and / or at least one driver package based on the version number, including: moving at least one driver and / or at least one driver package to a directory of a specified Nexus repository based on the version number.

[0025] Thirdly, the present invention also provides an electronic device including a processor, the processor being configured to implement the steps of any of the drive management methods described above when executing a computer program stored in a memory.

[0026] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of any of the driver management methods described above.

[0027] In this application, the Nexus repository is connected via the Nexus repository manager, and driver management is performed through Maven components, the Spring Boot framework, and the Nexus repository. Therefore, the technical boundaries of Maven are expanded, and driver management for multiple platforms, architectures, and file types is achieved by relying on the Nexus repository. Attached Figure Description

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0029] Figure 1 This is a schematic diagram of a drive management method provided in an embodiment of the present invention;

[0030] Figure 2 This is a schematic diagram illustrating a drive management method provided in an embodiment of the present invention;

[0031] Figure 3 A schematic diagram illustrating another drive management method provided in an embodiment of the present invention;

[0032] Figure 4 A schematic diagram illustrating another drive management method provided in an embodiment of the present invention;

[0033] Figure 5 A schematic diagram illustrating another drive management method provided in an embodiment of the present invention;

[0034] Figure 6 This is a schematic diagram of a modular structure of a drive management device provided in an embodiment of the present invention;

[0035] Figure 7 This is a schematic diagram of a drive management device provided in an embodiment of the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0037] To achieve more comprehensive drive management, embodiments of the present invention provide a drive management method, apparatus, device, and medium.

[0038] The following is an explanation of the terms used in this application:

[0039] Nexus: Nexus is a powerful dependency management repository that supports managing various dependency files, including Maven, PyPI, and Raw. This invention uses the open-source Sonatype Nexus Operation Support Systems (OSS) to manage Maven dependencies.

[0040] Maven: Maven is a project management tool that can build and manage dependencies for Java projects.

[0041] Spring Boot: Spring Boot is the starting point for all projects developed based on Spring. Based on the principle of convention over configuration, Spring Boot allows developers to focus entirely on writing business logic code without having to switch between configuration and business logic, thus greatly improving development efficiency and shortening project cycles to some extent.

[0042] Figure 1This application provides a schematic diagram of the structure of a driver management system. The system includes a protocol adaptation module, a service logic module, a driver management module, a driver package management module, and a Spring Boot framework module. The protocol adaptation module may include a Maven Artifact Resolver and a Nexus RESTful API based on representation state transition. The service logic module may include a service registration module, a session management module, and a service resource update module. The driver management module may include a driver upload module, a dependency library upload module, a driver version management module, a driver path management module, and a driver platform management module. The driver package management module may include a legal entity management module, a driver packaging module, a driver package version management module, and a driver legal entity attribution management module. The system can establish connections with the Nexus repository manager and a browser. The browser is used to initiate driver management commands, which may include driver management, driver packaging, and driver download. It should be understood that in some cases, driver management commands can also be initiated by other terminal devices. The above modules are described below in conjunction with method embodiments.

[0043] Specifically, the system uses the Spring Boot framework to build an independent driver library management system. Relying on Maven components and the subsequent Nexus repository, it extends Maven components while adhering to their original functionality as much as possible. This overcomes the limitation of Maven, which can only manage drivers for Java projects, and achieves the goal of managing multiple platforms (Windows, Linux, Android, etc.), multiple architectures (X86, ARM64, etc.), and multiple types of driver files (dll, so, ini, jar, etc.).

[0044] The following description uses a driver management system as the execution entity to illustrate the driver management method provided in this application. In other words, the driver management system mentioned in this application can be... Figure 1 The driver management system in the system.

[0045] Figure 2 This invention provides a schematic diagram of a driver management method, which includes the following steps:

[0046] S201: The driver management system connects to the Nexus repository through the Nexus repository manager. Nexus is a powerful dependency package management repository that supports storing various dependency files in formats such as Maven, PyPI, and Raw. The Nexus repository manager is used to manage the Nexus repository. For example, it can be used to upload third-party project JAR files to the Nexus repository for use by other project teams, or to download the address of a specific project from the Nexus repository to the index directory.

[0047] For example, embodiments of this application use the open-source Sonatype Nexus repository operation support system to manage Maven dependencies.

[0048] S202: The driver management system performs at least one of the following: driver management, driver package management, or driver version management through Maven components, the Spring Boot framework, and the Nexus repository.

[0049] Specifically, the driver management system can add driver files to the Nexus repository; it can also modify the information of any driver file in the Nexus repository. Similarly, the driver management system can create driver packages in the Nexus repository; it can also modify the information of any driver package in the Nexus repository. In addition, the driver management system can update the version number of driver files and / or driver packages based on the modification operations, and manage driver files with different version numbers.

[0050] Optionally, when modifying driver files and / or driver packages, older versions can be deleted or retained. That is, modifying driver files and / or driver packages can either overwrite (replace) the original driver files and / or driver packages, or create a new (group of) driver files and / or driver packages.

[0051] In one possible implementation of S202, driver information can be obtained; and driver management can be performed based on the driver information.

[0052] Optionally, after obtaining the driver information, it can be stored in the Nexus repository. In this way, the driver management system of this application does not need to use a database; it only relies on the Nexus repository to complete driver storage, facilitating deployment.

[0053] Optionally, the driver information includes at least one of the following: the driver group to which the driver belongs, the driver name, the driver version number, or the driver's dependency information with other drivers. For example, the obtained driver information includes parameters such as the driver file version number, the file type to which the driver belongs, the driver name, the driver version number, the driver packaging address (or path, directory), and the names and versions of the driver's dependent packages. Compared to the original Maven components that hard-code the driver package distribution path, this invention implements the function of managing drivers according to their corresponding paths.

[0054] For example, suppose the driver name in the driver management system is "Driver 1" and the driver address is "D:\Download". If the obtained driver information includes the driver name being "Driver 2" and the driver address being "C:\Users\Music", the driver management system will change the driver name to "Driver 2" and the driver address to "C:\Users\Music" based on this information. Alternatively, if the obtained driver information includes a new driver file, this driver file can be stored in the Nexus repository based on this information.

[0055] Optionally, the driver information may include basic driver information, which can be based on... Figure 3 The following steps are shown to manage the driver:

[0056] S301: Determine the basic information of the driver. Specifically, this includes: querying the previous driver version information, and combining it with the obtained driver information to determine the driver's group, driver name, and driver version number.

[0057] For example, driver version updates include major driver version updates, minor driver updates, and developer-specified updates. Major driver version updates may require mandatory updates, such as adding new interfaces or changing existing interfaces. Minor driver updates do not involve interface changes and are usually compatible with previous versions, specifically for example, bug fixes or performance optimizations. Developer-specified updates include both of the above categories, with content arranged from smallest to largest and without repetition, allowing differentiation between each packaged driver.

[0058] S302: Determine driver dependency information. This includes: querying the previous driver version information, combining it with the obtained driver information, and selecting the corresponding dependent driver, which is the driver file that has a dependency relationship with the current driver.

[0059] S303: Submit driver information to the repository through the driver management module. Specifically, this includes generating a first Project Object Model (POM) based on the information determined above, and submitting the first POM to the repository. A POM is a management file generated by Maven. The first POM in this application may include driver information and commands, conditions, etc., for managing operations performed on the driver. When the conditions are met, management operations on the driver can be performed through the first POM. Subsequent implementations of the second POM, third POM, etc., in this application can refer to the first POM.

[0060] S304: The driver management system creates a project object directory for drivers through a repository and stores the project object files and the first POM file. The project object directory includes the dependencies between the driver and other drivers.

[0061] In one possible implementation of S202, driver package information can be obtained; driver package management is then performed based on this information. A driver package includes multiple drivers belonging to the same driver group; that is, a driver package is a collection of driver files. The driver package information may include basic driver package information and / or driver package version update instructions.

[0062] Optionally, after obtaining the driver package information, this information can be stored in the Nexus repository. In this way, the driver management system of this application does not need to use a database; it only relies on the Nexus repository to complete driver storage, facilitating deployment.

[0063] Optionally, the driver package information is used to indicate at least one of the following: the legal entity to which multiple drivers belong, the name of multiple drivers, or their version number. For example, the obtained driver package information includes various parameters such as the legal entity of each driver in the driver package and the version number of each driver in the driver package. Using this method, the system can realize driver file management functions on a legal entity basis, facilitating rapid packaging and output according to the needs of legal entity customers. The legal entity can be identified by a group ID. For example, drivers belonging to the same legal entity have a group ID corresponding to that legal entity. In this application, the legal entity refers to the owner of the driver.

[0064] For example, suppose the legal entity of the driver package in the driver management system is "User A", and the obtained driver package information includes that the legal entity of the driver package is "User B". The driver management system changes the legal entity of the driver package to "User B" based on this information.

[0065] Optional, can be based on Figure 4 The following steps are shown for driver package management:

[0066] S401: Determine the basic information of the driver package. Specifically, this includes determining the legal entity, name, and version of the driver package based on its information.

[0067] S402: Determine the dependencies between multiple drivers in the driver package. Specifically, this includes: querying the preceding driver files and, based on the obtained driver package information, determining the dependencies between each driver file.

[0068] S403: Determine the second POM through the driver package management module. Specifically, this includes: generating the second POM based on the information determined above, and submitting the second POM to the repository.

[0069] S404: The driver management system creates a project object directory for the driver package through a repository, and stores the project object files and the second POM file. The project object directory includes the dependencies between the driver files in the driver package and other drivers.

[0070] Optional, such as Figure 4 As shown, when the driver package information includes driver package version update instructions, driver package management may also include the following steps:

[0071] S405: Driver package upgrade. Specifically, this includes determining the driver package that needs to be upgraded based on the information in the driver package.

[0072] S406: Determine the new version. Specifically, this includes determining the new version number based on the information in the aforementioned driver package.

[0073] S407: Remove drivers that are no longer needed. Specifically, this includes removing dependent drivers from the driver package based on the driver package information.

[0074] S408: Add new dependent drivers. Specifically, this includes adding the dependent drivers corresponding to the driver files in the driver package based on the driver package information.

[0075] S409: Determine the third POM through the driver package management module. Specifically, this includes: generating the third POM based on the information determined above, and submitting the third POM to the repository.

[0076] S410: The driver management system creates a project object directory for the driver package through a repository, and stores the project object files and third-party POM files. The project object directory includes the dependencies between the driver files in the driver package and other drivers.

[0077] It should be understood that the operations from steps S405 to S410 may not be performed in some cases.

[0078] In one possible implementation of S202, a version number can be obtained; version number management can be performed on at least one driver and / or at least one driver package based on the version number. For example, after obtaining the version number, the corresponding driver or driver package can be selected based on the version number, and the driver or driver package can be exported.

[0079] Optionally, at least one driver and / or at least one driver package can be moved to a specified Nexus repository directory, based on the version number.

[0080] Optional, can be based on Figure 5 The following steps are shown to manage the driver:

[0081] S501: Driver packages can also be queried based on the legal entity. Specifically, this includes: obtaining legal entity information, and then querying at least one driver package corresponding to that legal entity. The legal entity information may be, for example, the group identifier of the legal entity.

[0082] S502: Determine the driver packages to be exported. Specifically, this includes determining the driver packages to be exported based on the driver packages retrieved above and the obtained version numbers.

[0083] S503: Download all dependent drivers corresponding to the driver files in the driver package that needs to be exported. Specifically, this includes downloading all corresponding dependent drivers based on the POM of the driver package and storing the addresses of all dependent drivers in a temporary directory.

[0084] S504: File Organization. Specifically, this includes determining where to store all dependent driver files and / or file information in a specified directory based on the directory information corresponding to the driver package.

[0085] S505: Export the required version package from the specified directory. This version package may include files and / or file information in the specified directory.

[0086] Optionally, a RESTful API can be provided for the aforementioned driver management system to facilitate integration with various applications.

[0087] Optionally, a separate page can be provided for the aforementioned driver management system to facilitate user operation.

[0088] Based on the same concept as the above-described drive management method, this application also provides a drive management device for implementing the above-described method.

[0089] Figure 6 The diagram shown is a modular structure schematic of a drive management device provided in an embodiment of this application.

[0090] The creation module 601 can be used to perform creation actions, and the management module 602 can be used to implement management actions. For example, when implementing the driver management system described in the above method embodiments using this structure, the creation module 601 can be used to perform the action in S201 where the driver management system connects to the Nexus repository through the Nexus repository manager, and the management module 602 can be used to perform the action in S202 where the driver management system performs at least one of the following actions: driver management, driver package management, or driver version management through the Maven component, the Spring Boot framework, and the Nexus repository. The specific actions and functions performed will not be elaborated here, but can be referred to the description in the foregoing method embodiment section.

[0091] Figure 7 A schematic diagram of the device structure of a drive management method provided in an embodiment of this application is shown.

[0092] The electronic device in this application embodiment may include a processor 701. The processor 701 is the control center of the device, and can connect to various parts of the device using various interfaces and lines, by running or executing instructions stored in the memory 702 and calling data stored in the memory 702. Optionally, the processor 701 may include one or more processing units. The processor 701 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 701. In some embodiments, the processor 701 and the memory 702 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0093] The processor 701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit, field-programmable gate array or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps executed by the drive management system disclosed in the embodiments of this application can be directly executed by the hardware processor, or executed by a combination of hardware and software modules in the processor.

[0094] In this embodiment of the application, the memory 702 stores instructions that can be executed by at least one processor 701. By executing the instructions stored in the memory 702, the at least one processor 701 can perform the aforementioned connection establishment process executed by the drive management system.

[0095] Memory 702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 702 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 702 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 702 in the embodiments of this application may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0096] In this embodiment, the device may further include a communication interface 703 through which the electronic device can transmit data. For example, if the electronic device is an electronic device corresponding to a driver management system, the communication interface 703 can be used to export the required driver version package.

[0097] Optional, can be made by Figure 7 The processor 701 (or processor 701 and memory 702) shown implements Figure 6 The management module 602 shown, and / or, is implemented by the communication interface 703. Figure 6 The creation module 601 is shown.

[0098] Based on the same inventive concept, embodiments of this application also provide a computer-readable storage medium that can store instructions, which, when executed on a computer, cause the computer to perform the operation steps provided in the above-described method embodiments. This computer-readable storage medium may be... Figure 7 The memory 702 shown.

[0099] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0100] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0101] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0102] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the functions specified in one or more boxes. Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, this application also intends to include such modifications and variations if they fall within the scope of the claims of this application and their equivalents.

Claims

1. A drive management method, characterized in that, The method includes: Connect to the Nexus repository via Nexus repository manager; Obtain multiple non-Java driver files, which have the same driver grouping; the multiple non-Java driver files include driver files applicable to different operating system platforms and / or driver files applicable to different CPU architectures; The multiple non-Java driver files with the same driver group are combined into a driver package corresponding to the driver group. Determine the group identifier, name, and version number of the driver package; the group identifier is used to indicate the legal entity to which the multiple non-Java driver files belong, and non-Java driver files of the same legal entity have the same group identifier; Determine the basic information and dependency information of each non-Java driver file that constitutes the driver package. The non-Java driver file is a dynamic link library (DLL) file or a shared object (SO) file. The basic information includes the driver name and driver version number. The dependency information includes driver files that have dependencies on the non-Java driver files. Based on the group identifier, name, version number of the driver package, and the basic information and dependency information of each non-Java driver file, generate a project object model (POM) file corresponding to the driver package; The non-Java driver file and the POM file within the driver package are stored in the Nexus repository.

2. The method as described in claim 1, characterized in that, The basic information of the non-Java driver file includes at least one of the following: the driver group to which it belongs, the name of the non-Java driver file, or the version number of the non-Java driver file; the dependency information of the non-Java driver file includes the dependency relationship information between the non-Java driver file and other drivers.

3. The method as described in claim 1, characterized in that, The group identifier of the driver package is also used to indicate the name or version number of the plurality of non-Java driver files.

4. The method as described in claim 1 or 2, characterized in that, The method further includes: Get the version number; Version number management is performed on at least one driver package based on the version number.

5. The method as described in claim 4, characterized in that, The step of managing the version number of at least one driver package according to the version number includes: Based on the version number, move the at least one driver package to the specified directory of the Nexus repository.

6. A drive management device, characterized in that, This includes creating and managing modules: The creation module is used to connect to the Nexus repository through the Nexus repository manager; The management module is used to obtain multiple non-Java driver files, which have the same driver grouping; the multiple non-Java driver files include driver files applicable to different operating system platforms and / or driver files applicable to different CPU architectures. The management module is also used to: construct a driver package corresponding to the driver group from the multiple non-Java driver files that have the same driver group; The management module is also used to: determine the group identifier, name, and version number of the driver package; the group identifier is used to indicate the legal entity to which the multiple non-Java driver files belong, and non-Java driver files of the same legal entity have the same group identifier; The management module is further configured to: determine the basic information and dependency information of each non-Java driver file constituting the driver package, wherein the non-Java driver file includes a dynamic link library (DLL) file or a shared object (SO) file; the basic information includes the driver name and driver version number; and the dependency information includes driver files that have dependencies on the non-Java driver files. The management module is also used to: generate a Project Object Model (POM) file corresponding to the driver package based on the group identifier, name, version number of the driver package and the basic information and dependency information of each non-Java driver file; The management module is also used to store the non-Java driver files and the POM file in the driver package in the Nexus repository.

7. The apparatus as claimed in claim 6, characterized in that, The basic information of the non-Java driver file includes the driver group it belongs to, the name of the non-Java driver file, or the version number of the non-Java driver file; the dependency information of the non-Java driver file includes at least one of the dependency relationship information between the non-Java driver file and other drivers.

8. The apparatus as claimed in claim 6 or 7, characterized in that, The group identifier of the driver package is also used to indicate the name or version number of the plurality of non-Java driver files.

9. The apparatus as claimed in claim 6, characterized in that, The management module is also used for: Get the version number; Version number management is performed on at least one driver package based on the version number.

10. The apparatus as claimed in claim 9, characterized in that, The management module is specifically used for: Based on the version number, move the at least one driver package to the specified directory of the Nexus repository.

11. An electronic device, characterized in that, The electronic device includes a processor that executes a computer program stored in a memory to implement the steps of the method as described in any one of claims 1-5.

12. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1-5.

Images