CN112965913A - Method for automatically repairing dependency conflict problem of Java software - Google Patents
Method for automatically repairing dependency conflict problem of Java software Download PDFInfo
- Publication number
- CN112965913A CN112965913A CN202110338522.2A CN202110338522A CN112965913A CN 112965913 A CN112965913 A CN 112965913A CN 202110338522 A CN202110338522 A CN 202110338522A CN 112965913 A CN112965913 A CN 112965913A
- Authority
- CN
- China
- Prior art keywords
- dependency
- version
- risk
- conflict
- project
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3684—Test management for test design, e.g. generating new test cases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/3688—Test management for test execution, e.g. scheduling of test suites
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The application discloses a method for automatically repairing Java software dependency conflict problems, which finds out the dependency conflict problems by analyzing the dependency relationship of Java software projects and obtains classes and methods realized by programs and possible calling paths among the classes and methods by static analysis. The method sets 4 kinds of repair strategies, selects different strategies according to the risk types to load the risk-free versions into the current project, and selects the appropriate dependent versions according to the call path relation of the project to perform automatic version replacement, thereby helping developers to effectively avoid the problem of dependency conflict. And whether more dependency conflicts which can cause runtime errors are brought to the project or not can be evaluated while repairing, and finally, repairing patches and repairing reports are automatically formed to developers. The probability of running-time errors encountered by a developer in the development process and the time for solving the running-time errors are reduced, and the development cost is saved.
Description
Technical Field
The invention relates to the technical field of software reliability, in particular to a method for automatically repairing the dependency conflict problem of Java software.
Background
Under the efforts of a plurality of developers, Java software forms a huge third-party open-source dependent library. Although the third-party open-source dependency library brings great convenience to developers to develop the Java software project, the third-party open-source dependency library also brings trouble to the developers, namely how to manage a plurality of third-party dependency packages introduced in the Java software project. When a Java software project introduces a third-party dependent package, and the development of the third-party dependent package introduces other third-party dependent packages, a transfer condition is formed, and the condition hinders the management of the Java software project on the third-party dependent packages. Thus, the advent of Maven brings a good build management solution to the Java software project. Maven is a main building tool of a Java project and is also a main management tool of a third-party open source project introduced by the Java project. By injecting the required third party dependencies through the configuration file, Maven can automatically obtain all the dependency packages required by the project. Therefore, the method not only solves the management problem of the third party dependent package in the Java software project, but also provides great convenience for developing the Java software project
Maven is a good solution for Java build management, and although it can effectively manage third party dependent packages, it also causes problems. A third-party dependent package often performs functions updating, problem repairing, and the like, and after multiple updating iterations, multiple versions are generated. Since the dependency package required for introducing the dependency is transitionally introduced at the same time of introducing the dependency package, a Java software project often has multiple versions of the same dependency package. According to the Maven's dependency management mechanism, only one version is loaded into the item, and the other versions are masked, so that a dependency conflict phenomenon occurs. After a third-party dependent package is updated iteratively, the situation that a certain class or method exists in one version but does not exist in another version can occur, and when an item uses the method and actually loads a dependent version which does not contain the method, an error can occur in operation. When a Java software project has a dependency conflict problem, the dependency conflict problem may generate unexpected runtime errors while the project is running, such as Java. While Maven itself can identify dependency conflicts, there is a lack of an effective mechanism to help developers fix dependency conflicts.
The Maven build tool does not provide an effective solution to the problem of run-time errors caused by dependency conflicts in a Maven environment. Once a runtime error is encountered, it takes a significant amount of time to find the class and method that triggered the error, and then to find the method to fix the error. Repairing dependency conflicts by analyzing the relationships of classes and methods within a program can help software developers even further avoid program runtime crashes.
Disclosure of Invention
The technical problem to be solved by the invention is to provide a method for automatically repairing the dependency conflict problem of Java software aiming at the defects of the prior art
In order to solve the technical problems, the technical scheme adopted by the invention is as follows: a method for automatically repairing Java software dependence conflict problems comprises the following steps:
step 1: acquiring a project code and a dependency relationship of a current project;
step 2: analyzing the dependency relationship of the current project to obtain risk dependency conflicts and called risk methods, and dividing the risk dependency conflicts into conflicts with direct dependency and conflicts without direct dependency, wherein the process is as follows:
step 2.1: traversing a complete dependency tree of a current project, analyzing to obtain a dependency relationship of a plurality of versions in the complete dependency tree, and defining the dependency relationship as a dependency conflict;
step 2.2: for the dependency conflicts obtained by analysis, comparing and analyzing classes and methods in jar packages of the loaded versions and the unloaded versions, if the method in a jar package of the unloaded version does not have a corresponding method with the same limited name in the jar package of the loaded version, the method is a risk method, acquiring a method set, judging whether the method in the set is called in the current project or not, if so, the method is the risk dependency conflict, and acquiring the called risk method;
step 2.3: for the risk dependency conflict, checking whether the loading version of the conflict is the dependency of the current project direct statement or not through a dependency relationship graph, and if the loading version of the conflict is the dependency of the current project direct statement, determining that the conflict has direct dependency; otherwise, the conflict is no direct dependence.
And step 3: analyzing risk dependency conflicts, and finding a risk-free dependency version by judging whether the method in the loaded dependency version satisfies all the calls in the current project, wherein the process is as follows:
step 3.1: for risk dependency conflicts, analyzing whether the method of the unloaded dependency version meets all the calls of the method of the loaded dependency version in the project, if so, determining that the unloaded version is a risk-free version, and entering step 3.5; if not, entering the next step;
step 3.2: acquiring all release versions with risk dependence, deleting versions existing in risk conflict, filtering versions lower than the versions in risk conflict, and sequentially taking out test versions from the filtered versions in a centralized manner;
step 3.3: acquiring a jar packet of a test version, analyzing whether the method in the test version meets all the calls of the method in the loaded dependent version in the project, and if so, entering the next step; if not, testing the next version;
step 3.4: analyzing whether the methods in the test version contain the called risk methods in the unloaded dependent version, if so, determining the test version as a risk-free version;
step 3.5: the obtained unloaded version or the test version is a risk-free version.
And 4, step 4: setting a repair strategy, and selecting different strategies according to the risk types to load the risk-free versions into the current project;
the repair strategy comprises the following 4 types:
1: replace direct dependencies of current item: reading a dependent configuration file of a current project, positioning a declaration position on which a target directly depends, and performing version replacement;
2: unify to risk-free version using < dependency management > tag;
3: delete the version currently in use using the < excclose > tag;
4: directly declaring a risk-free version: and reading the dependency configuration file of the current project, and directly adding the statement of dependency on the risk-free version.
The process of selecting different strategies according to the risk types to load the risk-free versions into the current project is as follows:
step 4.1: after a risk-free version is obtained, judging the type of risk dependence conflict, if the conflict is directly dependent, carrying out version replacement by using strategies 1 and 2 in a repair strategy to generate a temporary repair patch; if the conflict is that the direct dependence does not exist, carrying out version replacement by using the strategies 2, 3 and 4 to generate a temporary repair patch;
step 4.2: analyzing the replaced dependency relationship for the repair patches corresponding to different replacement strategies, obtaining the current conflict-replaced loading version, and if the risk-free version is loaded correctly, then the replacement is successful; and if the risk-free version is not loaded correctly, the replacement fails, and the temporary repair patch corresponding to the failed replacement strategy is deleted.
And 5: evaluating whether the item using the repair strategy generates a new dependency conflict, as follows:
step 5.1: sequentially traversing all temporary repair patches to obtain the dependency generated by the temporary repair patches;
step 5.2: comparing the new dependency relationship generated by the patch with the original dependency relationship of the project, checking whether a dependency conflict different from the original project occurs, and if so, entering the next step; if not, entering step 5.4;
step 5.3: comparing and analyzing classes and methods in the jar packages of the loaded version and the unloaded version, if the method in the jar package of the unloaded version does not have a method with the same corresponding limited name in the jar package of the loaded version, the method is a risk method, obtaining the method set, judging whether the method in the set is called in the current project, and if the method in the set is called, repairing the patch inefficiently; if no call is made, the next step is carried out;
step 5.4: and backing up the temporary repair patch which is successfully evaluated into a folder designated by a user.
Step 6: the repair recommendations and repair patches are pushed to the developer.
Adopt the produced beneficial effect of above-mentioned technical scheme to lie in: the method provided by the invention not only can identify the dependency conflicts which can generate the runtime errors, but also can provide a reasonable repair scheme for the dependency conflicts which can generate the runtime errors. Corresponding repair suggestions and repair patches can be obtained only by using the method in the target Java project, so that the probability of running errors encountered by developers in the development process and the time for solving the running errors are reduced, and the development cost is saved.
Drawings
FIG. 1 is a flowchart of a method for automated recovery of Java software dependency conflict problems according to an embodiment of the present invention;
FIG. 2 is a flowchart of obtaining a risk-free dependent version according to an embodiment of the present invention;
FIG. 3 is a flowchart illustrating replacing a risk-free version with a repair policy according to an embodiment of the present invention;
fig. 4 is a flowchart illustrating an embodiment of evaluating whether a repair policy is valid.
Detailed Description
The following detailed description of embodiments of the present invention is provided in connection with the accompanying drawings and examples. The following examples are intended to illustrate the invention but are not intended to limit the scope of the invention.
As shown in fig. 1, the method for automatically repairing the Java software dependent conflict problem in this embodiment is as follows:
step 1: acquiring a project code and a dependency relationship of a current project;
in this embodiment, the project pom file is parsed by Maven to obtain the complete dependency tree of the project, because the Maven loading mechanism ensures that each dependency has only one version to be loaded for use, one complete dependency tree includes the dependency of project loading and the dependency that is not loaded, the complete dependency tree is traversed, each dependency on the dependency tree is regarded as a node and stored in a container of the program, and each node stores information including groupId, artifavtId, version, used, manage, parent, and the like.
Step 2: analyzing the dependency relationship of the current project to obtain risk dependency conflicts and called risk methods, and dividing the risk dependency conflicts into conflicts with direct dependency and conflicts without direct dependency, wherein the process is as follows:
step 2.1: traversing a complete dependency tree of a current project, analyzing to obtain a dependency relationship of a plurality of versions in the complete dependency tree, and defining the dependency relationship as a dependency conflict;
in this embodiment, because each dependency has a unique groupId and ArtifactId, if dependencies with the same groupId and ArtifactId appear in the complete dependency tree, but versions of the dependencies are different, a conflict of the dependencies is generated. Because only one version can be used by the item, the dependent isUsed value is checked, and if the dependent isUsed value is true, the dependent usedDepJar is defined as a loading version; if false, the unloaded version depends on the unpopuded DepJar. All identified dependency conflicts are placed in a dependency conflict container.
Step 2.2: for the dependency conflicts obtained by analysis, comparing and analyzing classes and methods in jar packages of the loaded versions and the unloaded versions, if the method in a jar package of the unloaded version does not have a corresponding method with the same limited name in the jar package of the loaded version, the method is a risk method, acquiring a method set, judging whether the method in the set is called in the current project or not, if so, the method is the risk dependency conflict, and acquiring the called risk method;
in this embodiment, the dependency conflict container is traversed, for each dependency conflict, classes and methods in jar packages of the loaded version and the unloaded version are analyzed, and for the analyzed method, if the method is not implemented in the loaded version and is implemented in the unloaded version, the method is stored in the testMethods set. The creation of a call graph of a project using root is a risk-dependent conflict if methods in the project are used as starting points and methods in the testMethods set can be addressed. The process was added to a risk methods set.
Step 2.3: for the risk dependency conflict, checking whether the loading version of the conflict is the dependency of the current project direct statement or not through a dependency relationship graph, and if the loading version of the conflict is the dependency of the current project direct statement, determining that the conflict has direct dependency; otherwise, the conflict is no direct dependence.
In this embodiment, for each risk dependency conflict, the parent value of the loaded version usedDepJar is obtained, and if the parent value of the node is not null, the node is a conflict Type A without direct dependency; otherwise, the conflict is a conflict Type B with direct dependence.
And step 3: analyzing risk dependency conflicts, and finding a risk-free dependency version by judging whether the method in the loaded dependency version satisfies all the calls in the current project, wherein the flow is shown in fig. 2, and the process is as follows:
step 3.1: for risk dependency conflicts, analyzing whether the method of the unloaded dependency version meets all the calls of the method of the loaded dependency version in the project, if so, determining that the unloaded version is a risk-free version, and entering step 3.5; if not, entering the next step;
in the embodiment, for each risky dependency conflict, all methods in the jar package of the loading version are analyzed, and a call graph call path diagram of the project is generated through the root. Starting with the method in the project, if the method in the loaded version can be addressed, the method is added to the usedMethods set. And (3) analyzing whether the method for analyzing the unloaded version contains all the methods in the user methods set, if so, determining that the unloaded version is a safe version without risk, and entering the step 3.5, otherwise, entering the next step.
Step 3.2: acquiring all release versions with risk dependence, deleting versions existing in risk conflict, filtering versions lower than the versions in risk conflict, and sequentially taking out test versions from the filtered versions in a centralized manner;
in this embodiment, all release versions of conflict dependency are acquired from the Maven repository, the versions are traversed, the loaded and unloaded versions of the conflict dependency are deleted, and the remaining versions are sorted from high to low and stored in the version set versions. And sequentially taking out the versions from the versions, and obtaining the dependent jar packets of the versions.
Step 3.3: acquiring a jar packet of a test version, analyzing whether the method in the test version meets all the calls of the method in the loaded dependent version in the project, and if so, entering the next step; if not, testing the next version;
in this embodiment, the method in the jar package of the test version is analyzed to obtain the usedMethods set in step 3.1, and if the method in the jar package of the test version can include all the methods in the usedMethods set, the next step is performed; and the other versions are tried instead.
Step 3.4: analyzing whether the methods in the test version contain the called risk methods in the unloaded dependent version, if so, determining the test version as a risk-free version;
in this embodiment, the risk methods set in step 2.2 is obtained, and if the method in the jar packet of the test version includes all methods in the risk methods set, the test version is a safe version without risk; and the next version is tried.
Step 3.5: the obtained unloaded version or the test version is a risk-free version.
And 4, step 4: setting a repair strategy, and selecting different strategies according to the risk types to load the risk-free versions into the current project;
the repair strategy comprises the following 4 types:
1: replace direct dependencies of current item: reading a dependent configuration file of a current project, positioning a declaration position on which a target directly depends, and performing version replacement;
2: unify to risk-free version using < dependency management > tag;
3: delete the version currently in use using the < excclose > tag;
4: directly declaring a risk-free version: and reading the dependency configuration file of the current project, and directly adding the statement of dependency on the risk-free version.
The process of selecting different strategies according to the risk types to load the risk-free versions into the current project is shown in fig. 3, and includes the following steps:
step 4.1: after a risk-free version is obtained, judging the type of risk dependence conflict, if the conflict is directly dependent, carrying out version replacement by using strategies 1 and 2 in a repair strategy to generate a temporary repair patch; if the conflict is that the direct dependence does not exist, carrying out version replacement by using the strategies 2, 3 and 4 to generate a temporary repair patch;
in this embodiment, a project pom.xml file is read, a code segment of a risk conflict is located, a code segment of a repair policy is used for replacement, and a sequence number of the replaced file combined with the used repair policy is named pom-repair.
Step 4.2: analyzing the replaced dependency relationship for the repair patches corresponding to different replacement strategies, obtaining the current conflict-replaced loading version, and if the risk-free version is loaded correctly, then the replacement is successful; and if the risk-free version is not loaded correctly, the replacement fails, and the temporary repair patch corresponding to the failed replacement strategy is deleted.
In this embodiment: obtaining the dependency relationship of each pom-repair.xml, checking whether the loading version of the risk dependency conflict is a replaced version, and if the replaced version is correctly loaded, copying the pom-copy.xml file into a temporary repair patch temp folder; if the risk-free version is not loaded correctly, the replacement fails.
And 5: the process of evaluating whether the project using the repair strategy generates a new dependency conflict is shown in fig. 4, and the process is as follows:
step 5.1: sequentially traversing all temporary repair patches pom-copy.xml to obtain the dependency relationship generated by the temporary repair patches;
step 5.2: comparing the new dependency relationship generated by the patch with the original dependency relationship of the project, checking whether a dependency conflict different from the original project occurs, and if so, entering the next step; if not, entering step 5.4;
in this embodiment, the dependency relationship of the temporary repair patch is analyzed to obtain a new dependency conflict set newConflicts, whether a dependency conflict that the original dependency conflict set does not have appears in the newConflicts set is checked by limiting the groupId and artifactId values, if yes, a new dependency conflict is defined, and the next step is performed; if no wool appears, go to step 5.4.
Step 5.3: comparing and analyzing classes and methods in the jar packages of the loaded version and the unloaded version, if the method in the jar package of the unloaded version does not have a method with the same corresponding limited name in the jar package of the loaded version, the method is a risk method, obtaining the method set, judging whether the method in the set is called in the current project, and if the method in the set is called, repairing the patch inefficiently; if no call is made, the next step is carried out;
in this embodiment, for a new dependency conflict, the class and method in the jar packages of the loaded version and the unloaded version are analyzed, and for the analyzed method, if the method is not implemented in the loaded version and is implemented in the unloaded version, the method is stored in the testMethod set. The call graph of the project is generated by using the root, and if the method in the project is taken as a starting point and the method in the testMethod set can be addressed, the repair patch is invalid.
Step 5.4: and backing up the temporary repair patch which is successfully evaluated into a folder designated by a user.
Step 6: the repair recommendations and repair patches are pushed to the developer.
In this embodiment, a repair suggestion report in the form of a text file is generated, where the report includes detailed information (a loaded version number and an unloaded version number, a structure dependent on a dependency tree, a call path of a risk method, and the like) of a risk dependency conflict, and an available repair policy and a file path of a repair patch that are proposed for the risk dependency conflict.
Claims (6)
1. A method for automatically repairing Java software dependence conflict problems is characterized by comprising the following steps:
step 1: acquiring a project code and a dependency relationship of a current project;
step 2: analyzing the dependency relationship of the current project to obtain risk dependency conflicts and called risk methods, and dividing the risk dependency conflicts into conflicts with direct dependency and conflicts without direct dependency;
and step 3: analyzing risk dependence conflicts, and searching risk-free dependence versions by judging whether the method in the loaded dependence versions meets all calls in the current project;
and 4, step 4: setting a repair strategy, and selecting different strategies according to the risk types to load the risk-free versions into the current project;
and 5: evaluating whether the project using the repair strategy generates new dependency conflicts;
step 6: the repair recommendations and repair patches are pushed to the developer.
2. The method for automatically repairing the Java software dependency conflict problem according to claim 1, wherein the process of the step 2 is as follows:
step 2.1: traversing a complete dependency tree of a current project, analyzing to obtain a dependency relationship of a plurality of versions in the complete dependency tree, and defining the dependency relationship as a dependency conflict;
step 2.2: for the dependency conflicts obtained by analysis, comparing and analyzing classes and methods in jar packages of the loaded versions and the unloaded versions, if the method in a jar package of the unloaded version does not have a corresponding method with the same limited name in the jar package of the loaded version, the method is a risk method, acquiring a method set, judging whether the method in the set is called in the current project or not, if so, the method is the risk dependency conflict, and acquiring the called risk method;
step 2.3: for the risk dependency conflict, checking whether the loading version of the conflict is the dependency of the current project direct statement or not through a dependency relationship graph, and if the loading version of the conflict is the dependency of the current project direct statement, determining that the conflict has direct dependency; otherwise, the conflict is no direct dependence.
3. The method for automated repairing of Java software dependent conflict problems according to claim 1, wherein: the process of the step 3 is as follows:
step 3.1: for risk dependency conflicts, analyzing whether the method of the unloaded dependency version meets all the calls of the method of the loaded dependency version in the project, if so, determining that the unloaded version is a risk-free version, and entering step 3.5; if not, entering the next step;
step 3.2: acquiring all release versions with risk dependence, deleting versions existing in risk conflict, filtering versions lower than the versions in risk conflict, and sequentially taking out test versions from the filtered versions in a centralized manner;
step 3.3: acquiring a jar packet of a test version, analyzing whether the method in the test version meets all the calls of the method in the loaded dependent version in the project, and if so, entering the next step; if not, testing the next version;
step 3.4: analyzing whether the methods in the test version contain the called risk methods in the unloaded dependent version, if so, determining the test version as a risk-free version;
step 3.5: the obtained unloaded version or the test version is a risk-free version.
4. The method for automated repairing of Java software dependency conflict problem according to claim 1, wherein the repairing strategy comprises 4 of the following:
1: replace direct dependencies of the current item;
2: unify to risk-free version using < dependency management > tag;
3: delete the version currently in use using the < excclose > tag;
4: a risk-free version is declared directly.
5. The method for automatically repairing the Java software dependency conflict problem as claimed in claim 1, wherein the process of selecting different strategies according to risk types to load risk-free versions into the current project is as follows:
step 4.1: after a risk-free version is obtained, judging the type of risk dependence conflict, if the conflict is directly dependent, carrying out version replacement by using strategies 1 and 2 in a repair strategy to generate a temporary repair patch; if the conflict is that the direct dependence does not exist, carrying out version replacement by using the strategies 2, 3 and 4 to generate a temporary repair patch;
step 4.2: analyzing the replaced dependency relationship for the repair patches corresponding to different replacement strategies, obtaining the current conflict-replaced loading version, and if the risk-free version is loaded correctly, then the replacement is successful; and if the risk-free version is not loaded correctly, the replacement fails, and the temporary repair patch corresponding to the failed replacement strategy is deleted.
6. The method for automatically repairing the Java software dependency conflict problem according to claim 1, wherein the process of the step 5 is as follows:
step 5.1: sequentially traversing all temporary repair patches to obtain the dependency generated by the temporary repair patches;
step 5.2: comparing the new dependency relationship generated by the patch with the original dependency relationship of the project, checking whether a dependency conflict different from the original project occurs, and if so, entering the next step; if not, entering step 5.4;
step 5.3: comparing and analyzing classes and methods in the jar packages of the loaded version and the unloaded version, if the method in the jar package of the unloaded version does not have a method with the same corresponding limited name in the jar package of the loaded version, the method is a risk method, obtaining the method set, judging whether the method in the set is called in the current project, and if the method in the set is called, repairing the patch inefficiently; if no call is made, the next step is carried out;
step 5.4: and backing up the temporary repair patch which is successfully evaluated into a folder designated by a user.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110338522.2A CN112965913B (en) | 2021-03-26 | 2021-03-26 | Java software dependency conflict problem automatic repairing method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110338522.2A CN112965913B (en) | 2021-03-26 | 2021-03-26 | Java software dependency conflict problem automatic repairing method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112965913A true CN112965913A (en) | 2021-06-15 |
| CN112965913B CN112965913B (en) | 2023-09-26 |
Family
ID=76279669
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110338522.2A Active CN112965913B (en) | 2021-03-26 | 2021-03-26 | Java software dependency conflict problem automatic repairing method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112965913B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113254055A (en) * | 2021-06-29 | 2021-08-13 | 中航信移动科技有限公司 | Invalid dependency deletion method and device, computer equipment and storage medium |
| CN113434394A (en) * | 2021-06-22 | 2021-09-24 | 青岛海尔科技有限公司 | Software exception handling method and device, storage medium and electronic device |
| CN114675839A (en) * | 2022-05-30 | 2022-06-28 | 炫彩互动网络科技有限公司 | Code warehouse Java conflict file sorting and grouping method based on directed graph |
| CN115016840A (en) * | 2022-06-30 | 2022-09-06 | 厦门大学 | Dependency conflict repairing method and device based on call graph |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080320473A1 (en) * | 2007-06-21 | 2008-12-25 | James Laska | Methods and systems for dynamically generating installation configuration files for software |
| WO2009082653A1 (en) * | 2007-12-20 | 2009-07-02 | Hsbc Technologies Inc. | Automated methods and systems for developing and deploying projects in parallel |
| US20120110093A1 (en) * | 2010-11-01 | 2012-05-03 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| US20150143355A1 (en) * | 2010-11-01 | 2015-05-21 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| WO2017212496A2 (en) * | 2016-06-08 | 2017-12-14 | Veriversion Labs Ltd. | Methods and systems of software testing, distribution, installation and deployment |
| CN108121590A (en) * | 2017-11-29 | 2018-06-05 | 杭州九略智能科技有限公司 | The method and device of ESXI virtual machine automatic deployment installation systems |
| CN108984416A (en) * | 2018-08-07 | 2018-12-11 | 东北大学 | Conflict hazard class method for distinguishing is relied in a kind of assessment Maven environment |
| CN109343841A (en) * | 2018-10-15 | 2019-02-15 | 上海理工大学 | Semantic conflict digestion procedure under real-time collaborative programmed environment |
| US20200364042A1 (en) * | 2019-05-17 | 2020-11-19 | Sap Se | Static analysis of higher-order merge conflicts in large software development projects |
| CN112181858A (en) * | 2020-11-09 | 2021-01-05 | 东北大学 | Automatic detection method for Java software project dependent conflict semantic consistency |
-
2021
- 2021-03-26 CN CN202110338522.2A patent/CN112965913B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080320473A1 (en) * | 2007-06-21 | 2008-12-25 | James Laska | Methods and systems for dynamically generating installation configuration files for software |
| WO2009082653A1 (en) * | 2007-12-20 | 2009-07-02 | Hsbc Technologies Inc. | Automated methods and systems for developing and deploying projects in parallel |
| US20120110093A1 (en) * | 2010-11-01 | 2012-05-03 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| US20150143355A1 (en) * | 2010-11-01 | 2015-05-21 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| WO2017212496A2 (en) * | 2016-06-08 | 2017-12-14 | Veriversion Labs Ltd. | Methods and systems of software testing, distribution, installation and deployment |
| CN108121590A (en) * | 2017-11-29 | 2018-06-05 | 杭州九略智能科技有限公司 | The method and device of ESXI virtual machine automatic deployment installation systems |
| CN108984416A (en) * | 2018-08-07 | 2018-12-11 | 东北大学 | Conflict hazard class method for distinguishing is relied in a kind of assessment Maven environment |
| CN109343841A (en) * | 2018-10-15 | 2019-02-15 | 上海理工大学 | Semantic conflict digestion procedure under real-time collaborative programmed environment |
| US20200364042A1 (en) * | 2019-05-17 | 2020-11-19 | Sap Se | Static analysis of higher-order merge conflicts in large software development projects |
| CN112181858A (en) * | 2020-11-09 | 2021-01-05 | 东北大学 | Automatic detection method for Java software project dependent conflict semantic consistency |
Non-Patent Citations (1)
| Title |
|---|
| 邵飞: "基于依赖关系的软件需求建模与优先级评估方法研究", 《中国博士学位论文全文数据库信息科技辑》, no. 06, pages 138 - 26 * |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113434394A (en) * | 2021-06-22 | 2021-09-24 | 青岛海尔科技有限公司 | Software exception handling method and device, storage medium and electronic device |
| CN113434394B (en) * | 2021-06-22 | 2023-07-21 | 青岛海尔科技有限公司 | Abnormality processing method and device for software, storage medium and electronic device |
| CN113254055A (en) * | 2021-06-29 | 2021-08-13 | 中航信移动科技有限公司 | Invalid dependency deletion method and device, computer equipment and storage medium |
| CN113254055B (en) * | 2021-06-29 | 2021-09-28 | 中航信移动科技有限公司 | Invalid dependency deletion method and device, computer equipment and storage medium |
| CN114675839A (en) * | 2022-05-30 | 2022-06-28 | 炫彩互动网络科技有限公司 | Code warehouse Java conflict file sorting and grouping method based on directed graph |
| CN115016840A (en) * | 2022-06-30 | 2022-09-06 | 厦门大学 | Dependency conflict repairing method and device based on call graph |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112965913B (en) | 2023-09-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112965913B (en) | Java software dependency conflict problem automatic repairing method | |
| US11366747B2 (en) | Unified test automation system | |
| US10509693B2 (en) | Method for identifying a cause for a failure of a test | |
| US8954930B2 (en) | System and method for reducing test effort by object risk analysis | |
| US8434054B2 (en) | System and method for managing cross project dependencies at development time | |
| US9880832B2 (en) | Software patch evaluator | |
| US10579513B2 (en) | Test run control method and apparatus | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| US20200034282A1 (en) | Object-oriented regression-candidate filter | |
| US10514898B2 (en) | Method and system to develop, deploy, test, and manage platform-independent software | |
| US20030088810A1 (en) | Methods and apparatus for determining software component sizes associated with errors | |
| CN110543427A (en) | Test case storage method and device, electronic equipment and storage medium | |
| CN112631607A (en) | Method for detecting dependency conflict in python environment | |
| CN112860312A (en) | Method and device for detecting item dependency relationship change | |
| CN106708550B (en) | Method and device for loading shared object library | |
| CN111767164B (en) | Method and system for positioning component to which crash stack belongs in assembled product | |
| CN111352631B (en) | Interface compatibility detection method and device | |
| CN111240719B (en) | Defect-driven third-party library version upgrade recommendation method | |
| Nguyen et al. | An empirical study of exception handling bugs and fixes | |
| CN117311797A (en) | Software library version safety replacement method based on static analysis | |
| Artho | Iterative delta debugging | |
| CN115934157B (en) | Automatic software dependency range deducing method, device, computer equipment and memory | |
| CN116149707B (en) | Method and device for detecting and avoiding upgrading risk of distributed system | |
| CN117313088A (en) | Java program dead code detection method based on abstract syntax tree and iteration | |
| CN114168972A (en) | Npm ecosystem security vulnerability blocking point detection and repair method |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |