CN112965913B - Java software dependency conflict problem automatic repairing method - Google Patents
Java software dependency conflict problem automatic repairing method Download PDFInfo
- Publication number
- CN112965913B CN112965913B CN202110338522.2A CN202110338522A CN112965913B CN 112965913 B CN112965913 B CN 112965913B CN 202110338522 A CN202110338522 A CN 202110338522A CN 112965913 B CN112965913 B CN 112965913B
- Authority
- CN
- China
- Prior art keywords
- version
- risk
- dependency
- conflict
- dependent
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 127
- 230000001419 dependent effect Effects 0.000 claims abstract description 39
- 238000012360 testing method Methods 0.000 claims description 21
- 238000001914 filtration Methods 0.000 claims description 3
- 230000003068 static effect Effects 0.000 abstract 1
- 238000007726 management method Methods 0.000 description 5
- 238000010998 test method Methods 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
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)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (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 items, and obtains classes and methods realized by a program and possible call paths between the classes and the methods by static analysis. According to the application, 4 repair strategies are set, different strategies are selected according to the risk types, the risk-free version is loaded into the current project, and an appropriate dependent version is selected according to the calling path relation of the project to perform automatic version replacement, so that a developer is helped to effectively avoid the problem of dependence conflict. And the method can evaluate whether more dependence conflicts which can cause errors in running can be brought to the project while repairing, and finally, repairing patches and repairing reports can be automatically formed to developers. The probability of running errors encountered by a developer in the development process is reduced, the time for solving the running errors is shortened, and the development cost is saved.
Description
Technical Field
The application relates to the technical field of software reliability, in particular to a Java software dependency conflict problem automatic repairing method.
Background
Java software forms a huge third-party open-source dependency library under the efforts of many developers. While the third party open source dependency library brings great convenience to the developer in developing Java software projects, it also brings trouble to the developer in how to manage the various third party dependency packages introduced in Java software projects. When a Java software project introduces a third party dependency package, and the development of the third party dependency package introduces other third party dependency packages, a delivery situation is formed, and the situation prevents the Java software project from managing the third party dependency package. Thus, the advent of Maven has brought a good build management solution to the Java software project. Maven is a main construction tool of Java projects and is also a main management tool of third party open source projects introduced by Java projects. By injecting the required third-party dependencies into the configuration file, maven can automatically obtain all the dependency packages required for the project. Thus, not only the management problem of the third party dependency package in the Java software project is solved, but also great convenience is provided for developing the Java software project
Maven, a good solution for Java build management, is able to effectively manage third party dependent packages, but it also presents problems. A third party dependency package often performs processes such as function update and problem repair, and multiple versions are generated after multiple update iterations. Since the dependency package required for the dependency is introduced transitively while the dependency package is introduced, there are often multiple versions of the same dependency package for one Java software project. According to the Maven dependency management mechanism, only one version is loaded into the project, and other versions are shielded, so that a dependency conflict phenomenon occurs. After a third party dependency package is iteratively updated, a situation that a certain class or method exists in one version but does not exist in another version occurs, and when an item uses the method and is actually loaded by a dependency version which does not contain the method, an error occurs in the running process. When a Java software project has a dependency conflict problem, in the case of insufficient integration test, the dependency conflict problem may generate unexpected runtime errors, such as Java. Maven itself, while able to identify dependency conflicts, lacks an effective mechanism to help developers repair dependency conflicts.
The Maven build tool does not provide an effective solution to the problem of run-time errors caused by dependencies in the 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 find the method to fix the error. Repairing dependency conflicts by analyzing the relationships of classes and methods inside the program can further help software developers avoid program runtime crashes.
Disclosure of Invention
The technical problem to be solved by the application is to provide a Java software dependency conflict problem automatic repairing method aiming at the defects of the prior art
In order to solve the technical problems, the application adopts the following technical scheme: a Java software dependence conflict problem automatic repairing method comprises the following steps:
step 1: acquiring item codes and dependency relations of the current item;
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 dependencies and conflicts without direct dependencies, wherein the process is as follows:
step 2.1: traversing the complete dependency tree of the current project, analyzing to obtain dependency relationships with a plurality of versions in the complete dependency tree, and defining the dependency relationships as dependency conflicts;
step 2.2: comparing and analyzing classes and methods in the loaded version jar package with those in the unloaded version jar package, if one method in the unloaded version jar package does not have the corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, obtaining the called risk method;
step 2.3: for risk dependency conflicts, checking whether the conflicting loaded version is directly declared dependent of the current item through a dependency graph, and if so, judging that the conflict is directly dependent; otherwise, there is no direct dependent conflict.
Step 3: analyzing risk dependency conflicts, and searching for a risk-free dependency version by judging whether methods in the loaded dependency version meet all calls in the current project or not, wherein the process is as follows:
step 3.1: for risk dependency conflict, analyzing whether the unloaded dependent version method meets all calls of the loaded dependent version method in the project, if so, 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 of risk dependence, deleting versions existing in risk conflicts, filtering versions lower than version numbers in the risk conflicts, and sequentially and intensively extracting test versions from the filtered versions;
step 3.3: acquiring a jar packet of a test version, analyzing whether a method in the test version meets all calls of the method in the loaded dependent version in a project, and if so, entering the next step; if not, testing the next version;
step 3.4: analyzing whether the method in the test version contains the called risk method in the unloaded dependent version, and if so, obtaining a risk-free version;
step 3.5: the resulting unloaded or tested version is a risk-free version.
Step 4: setting a repair strategy, and selecting different strategies according to the risk type to load the risk-free version into the current project;
the repair strategy comprises the following 4 types:
1: direct dependence of replacement current item: reading a dependence configuration file of a current item, positioning a statement position directly depended on by a target, and carrying out version replacement;
2: unifying to risk-free versions using a < dependencylmanagement > tag;
3: deleting the currently used version using the < include > tag;
4: directly declaring a risk-free version: and reading the dependency configuration file of the current project, and directly adding a statement of dependency on the risk-free version.
The process of selecting different strategies according to the risk type to load the risk-free version into the current project is as follows:
step 4.1: judging the type of risk dependence conflict after obtaining a risk-free version, and if the risk-dependent conflict exists, performing version replacement by using strategies 1 and 2 in the repair strategy to generate a temporary repair patch; if no direct dependence conflicts exist, performing version replacement by using strategies 2, 3 and 4 to generate a temporary repair patch;
step 4.2: analyzing the dependency relationship after replacement for the repair patches corresponding to different replacement strategies, acquiring the loaded version after the current conflict replacement, and if the version without risk is loaded correctly, replacing successfully; 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.
Step 5: the process of evaluating whether an item after using a repair policy generates a new dependency conflict is as follows:
step 5.1: traversing all temporary repair patches in sequence to acquire a 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 to check whether dependency conflict different from the original project occurs, and if so, entering the next step; if not, go to step 5.4;
step 5.3: comparing and analyzing classes and methods in the loaded version jar package and the unloaded version jar package, if a method in one unloaded version jar package does not have a corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, invalidating the repair patch; if no, entering the next step;
step 5.4: and backing up the temporary repair patch which is evaluated to be successful into a folder designated by a user.
Step 6: the repair suggestion and repair patch are pushed to the developer.
The beneficial effects of adopting above-mentioned technical scheme to produce lie in: the method provided by the application not only can identify the dependency conflicts which can possibly generate the runtime errors, but also can provide a reasonable repairing scheme for the dependency conflicts which can possibly generate the runtime errors. The method can obtain the corresponding repair suggestion and repair patch only by using the method in the target Java project, reduces the probability of running errors encountered by a developer in the development process, solves the time of the running errors, and saves the development cost.
Drawings
FIG. 1 is a flowchart of a method for automatically repairing a Java software dependent conflict problem in an embodiment of the application;
FIG. 2 is a flow chart of the method for obtaining a risk-free version according to an embodiment of the present application;
FIG. 3 is a flow chart of replacement of a risk-free version with a repair strategy in an embodiment of the present application;
FIG. 4 is a flowchart of an embodiment of evaluating whether a repair policy is valid.
Detailed Description
The following describes in further detail the embodiments of the present application with reference to the drawings and examples. The following examples are illustrative of the application and are not intended to limit the scope of the application.
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 item codes and dependency relations of the current item;
in this embodiment, the Maven parses the item pon file to obtain a complete dependency tree of the item, and because the Maven loading mechanism ensures that only one version of each dependency is loaded and used, one complete dependency tree includes the dependency loaded by the item and the dependency 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, isUsed, 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 dependencies and conflicts without direct dependencies, wherein the process is as follows:
step 2.1: traversing the complete dependency tree of the current project, analyzing to obtain dependency relationships with a plurality of versions in the complete dependency tree, and defining the dependency relationships as dependency conflicts;
in this embodiment, because each dependency has a unique groupId and ArtifactId, if dependencies with the same groupId and the same ArtifactId occur in the complete dependency tree, and the dependencies are not identical in version, then a conflict of dependencies is generated. Because the item only uses one version, looking at the dependent used value, if true, defining as the loaded version dependent usedDepJar; if false, then the unloaded version depends on unused DepJar. All dependency conflicts identified are placed in the dependency conflict container.
Step 2.2: comparing and analyzing classes and methods in the loaded version jar package with those in the unloaded version jar package, if one method in the unloaded version jar package does not have the corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, obtaining 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 resolved, and for the resolved methods, if the method is not implemented in the loaded version but is implemented in the unloaded version, the methods are stored in the testMethods set. The call graph of the project is generated by using the root, and the method in the project is taken as a starting point, and if the method in the testMethods set can be addressed, the method is a risk dependent conflict. The method was added to the riskMethods set.
Step 2.3: for risk dependency conflicts, checking whether the conflicting loaded version is directly declared dependent of the current item through a dependency graph, and if so, judging that the conflict is directly dependent; otherwise, there is no direct dependent conflict.
In this embodiment, for each risk dependency conflict, a parent value of a loaded version usedDepJar is obtained, and if the node parent value is not null, the node parent value is a conflict Type a without direct dependency; and otherwise, a conflict Type B with direct dependence exists.
Step 3: analyzing risk dependency conflicts, and searching for a risk-free dependency version by judging whether a method in the loaded dependency version meets all calls in a current project, wherein the process is as shown in the figure 2, and the process is as follows:
step 3.1: for risk dependency conflict, analyzing whether the unloaded dependent version method meets all calls of the loaded dependent version method in the project, if so, the unloaded version is a risk-free version, and entering step 3.5; if not, entering the next step;
in this embodiment, for each dependency conflict with risk, all methods in the loaded version jar packet are resolved, and a call graph call path diagram of the item is generated through a boot. Starting with the method in the item, if a method in the loaded version can be addressed, the method is added to the usedMethods set. Analyzing whether the method of the unloaded version contains all methods in the usedMethods set, if so, the unloaded version is a safe version without risk, and entering step 3.5, otherwise, entering the next step.
Step 3.2: acquiring all release versions of risk dependence, deleting versions existing in risk conflicts, filtering versions lower than version numbers in the risk conflicts, and sequentially and intensively extracting test versions from the filtered versions;
in this embodiment, all release versions of the conflict dependency are obtained from the Maven repository, the versions are traversed, the conflict dependent loaded and unloaded versions are deleted, and the remaining versions are sorted from high to low into version set versions. And sequentially extracting the versions from the versions, and acquiring the dependent jar package of the version.
Step 3.3: acquiring a jar packet of a test version, analyzing whether a method in the test version meets all calls of the method in the loaded dependent version in a project, and if so, entering the next step; if not, testing the next version;
in this embodiment, the method in the test version jar packet is parsed, the usedfmethod set in step 3.1 is obtained, and if the method in the test version jar packet can include all the methods in the usedfmethod set, the next step is entered; whereas other versions are tried.
Step 3.4: analyzing whether the method in the test version contains the called risk method in the unloaded dependent version, and if so, obtaining a risk-free version;
in this embodiment, the riskMethods set in step 2.2 is obtained, and if the methods in the test version jar packet include all the methods in the riskMethods set, the test version is a risk-free security version; and otherwise try the next version.
Step 3.5: the resulting unloaded or tested version is a risk-free version.
Step 4: setting a repair strategy, and selecting different strategies according to the risk type to load the risk-free version into the current project;
the repair strategy comprises the following 4 types:
1: direct dependence of replacement current item: reading a dependence configuration file of a current item, positioning a statement position directly depended on by a target, and carrying out version replacement;
2: unifying to risk-free versions using a < dependencylmanagement > tag;
3: deleting the currently used version using the < include > tag;
4: directly declaring a risk-free version: and reading the dependency configuration file of the current project, and directly adding a statement of dependency on the risk-free version.
The process of selecting different strategies according to the risk type to load the risk-free version into the current project is shown in fig. 3, and includes the following steps:
step 4.1: judging the type of risk dependence conflict after obtaining a risk-free version, and if the risk-dependent conflict exists, performing version replacement by using strategies 1 and 2 in the repair strategy to generate a temporary repair patch; if no direct dependence conflicts exist, performing version replacement by using strategies 2, 3 and 4 to generate a temporary repair patch;
in this embodiment, the item pon.xml file is read, the code segment with risk conflict is located, the code segment with repair policy is used for replacement, and the sequence number of the repair policy used by combining the replaced file is named pon-repair.
Step 4.2: analyzing the dependency relationship after replacement for the repair patches corresponding to different replacement strategies, acquiring the loaded version after the current conflict replacement, and if the version without risk is loaded correctly, replacing successfully; 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, the following is the case: obtaining the dependency relationship of each pon-reply, checking whether the loading version with risk dependency conflict is a replacement version, if so, copying the pon-copy.xml file into a temporary repair patch temp folder; if the riskless version is not loaded correctly, the replacement fails.
Step 5: the project after the repair strategy is evaluated whether a new dependency conflict is generated, and the process is as follows, wherein the process is shown in fig. 4:
step 5.1: traversing all the temporary repair patches pore-copy.xml in sequence to acquire 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 to check whether dependency conflict different from the original project occurs, and if so, entering the next step; if not, go to step 5.4;
in this embodiment, the dependency relationship of the temporary repair patch is analyzed to obtain a new dependency conflict set newConflicts, and whether the dependency conflict in the original dependency conflict set does not exist in the newConflicts set is checked by limiting the groupId and artifactId values, if so, the new dependency conflict is defined, and the next step is entered; if no woolen cloth appears, the process proceeds to step 5.4.
Step 5.3: comparing and analyzing classes and methods in the loaded version jar package and the unloaded version jar package, if a method in one unloaded version jar package does not have a corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, invalidating the repair patch; if no, entering the next step;
in this embodiment, for a new dependency conflict, classes and methods in jar packages of a loaded version and an unloaded version are resolved, and for the resolved method, if the method is not implemented in the loaded version but implemented in the unloaded version, the method is stored in the testMethod set. And generating a call graph of the project by utilizing the root, taking a method in the project as a starting point, and if the method in the testMethod set can be addressed, invalidating the repair patch.
Step 5.4: and backing up the temporary repair patch which is evaluated to be successful into a folder designated by a user.
Step 6: the repair suggestion and repair patch 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 (loaded version number and unloaded version number, structure in dependency tree, call path of risk method, etc.) of risk dependency conflict, available repair policy proposed for risk dependency conflict, and file path of repair patch.
Claims (5)
1. The Java software dependency conflict problem automatic repairing method is characterized by comprising the following steps:
step 1: acquiring item codes and dependency relations of the current item;
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 dependencies and conflicts without direct dependencies;
step 3: analyzing risk dependency conflicts, and searching for a risk-free dependent version by judging whether methods in the loaded dependent version meet all calls in the current project;
step 3.1: for risk dependency conflict, analyzing whether the unloaded dependent version method meets all calls of the loaded dependent version method in the project, if so, 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 of risk dependence, deleting versions existing in risk conflicts, filtering versions lower than version numbers in the risk conflicts, and sequentially and intensively extracting test versions from the filtered versions;
step 3.3: acquiring a jar packet of a test version, analyzing whether a method in the test version meets all calls of the method in the loaded dependent version in a project, and if so, entering the next step; if not, testing the next version;
step 3.4: analyzing whether the method in the test version contains the called risk method in the unloaded dependent version, and if so, obtaining a risk-free version;
step 3.5: the obtained unloaded version or test version is a risk-free version;
step 4: setting a repair strategy, and selecting different strategies according to the risk type to load the risk-free version into the current project;
step 5: evaluating whether the items after the repair strategy are used generate new dependency conflicts;
step 6: the repair suggestion and repair patch are pushed to the developer.
2. The method for automatically repairing a Java software dependent conflict problem according to claim 1, wherein the procedure of step 2 is as follows:
step 2.1: traversing the complete dependency tree of the current project, analyzing to obtain dependency relationships with a plurality of versions in the complete dependency tree, and defining the dependency relationships as dependency conflicts;
step 2.2: comparing and analyzing classes and methods in the loaded version jar package with those in the unloaded version jar package, if one method in the unloaded version jar package does not have the corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, obtaining the called risk method;
step 2.3: for risk dependency conflicts, checking whether the conflicting loaded version is directly declared dependent of the current item through a dependency graph, and if so, judging that the conflict is directly dependent; otherwise, there is no direct dependent conflict.
3. The method for automatically repairing a Java software dependent conflict problem according to claim 1, wherein the repairing policy comprises 4 kinds of following:
1: direct dependence of replacement current item;
2: unifying to risk-free versions using a < dependencylmanagement > tag;
3: deleting the currently used version using the < include > tag;
4: the risk-free version is declared directly.
4. A method for automated repair of Java software dependent conflict problems according to claim 3, wherein the process of selecting different policies according to risk type to load risk-free versions into the current project is as follows:
step 4.1: judging the type of risk dependence conflict after obtaining a risk-free version, and if the risk-dependent conflict exists, performing version replacement by using strategies 1 and 2 in the repair strategy to generate a temporary repair patch; if no direct dependence conflicts exist, performing version replacement by using strategies 2, 3 and 4 to generate a temporary repair patch;
step 4.2: analyzing the dependency relationship after replacement for the repair patches corresponding to different replacement strategies, acquiring the loaded version after the current conflict replacement, and if the version without risk is loaded correctly, replacing successfully; 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.
5. The method for automatically repairing a Java software dependent conflict problem according to claim 1, wherein the procedure of step 5 is as follows:
step 5.1: traversing all temporary repair patches in sequence to acquire a 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 to check whether dependency conflict different from the original project occurs, and if so, entering the next step; if not, go to step 5.4;
step 5.3: comparing and analyzing classes and methods in the loaded version jar package and the unloaded version jar package, if a method in one unloaded version jar package does not have a corresponding method with the same limiting name in the loaded version jar package, obtaining a method set, judging whether the method in the set is called in the current project, and if so, invalidating the repair patch; if no, entering the next step;
step 5.4: and backing up the temporary repair patch which is evaluated to be successful 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 CN112965913A (en) | 2021-06-15 |
| CN112965913B true 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) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113434394B (en) * | 2021-06-22 | 2023-07-21 | 青岛海尔科技有限公司 | Abnormality processing method and device for software, storage medium and electronic device |
| CN113254055B (en) * | 2021-06-29 | 2021-09-28 | 中航信移动科技有限公司 | Invalid dependency deletion method and device, computer equipment and storage medium |
| CN114675839B (en) * | 2022-05-30 | 2022-08-30 | 炫彩互动网络科技有限公司 | Code warehouse Java conflict file sorting and grouping method based on directed graph |
| CN115016840B (en) * | 2022-06-30 | 2024-08-02 | 厦门大学 | Dependency conflict restoration method and device based on call graph |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009082653A1 (en) * | 2007-12-20 | 2009-07-02 | Hsbc Technologies Inc. | Automated methods and systems for developing and deploying projects in parallel |
| 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 |
| CN112181858A (en) * | 2020-11-09 | 2021-01-05 | 东北大学 | Automatic detection method for Java software project dependent conflict semantic consistency |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8464247B2 (en) * | 2007-06-21 | 2013-06-11 | Red Hat, Inc. | Methods and systems for dynamically generating installation configuration files for software |
| US20150143355A1 (en) * | 2010-11-01 | 2015-05-21 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| US8898285B2 (en) * | 2010-11-01 | 2014-11-25 | Architecture Technology Corporation | Service oriented architecture version and dependency control |
| US11144311B2 (en) * | 2019-05-17 | 2021-10-12 | Sap Se | Static analysis of higher-order merge conflicts in large software development projects |
-
2021
- 2021-03-26 CN CN202110338522.2A patent/CN112965913B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2009082653A1 (en) * | 2007-12-20 | 2009-07-02 | Hsbc Technologies Inc. | Automated methods and systems for developing and deploying projects in parallel |
| 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 |
| CN112181858A (en) * | 2020-11-09 | 2021-01-05 | 东北大学 | Automatic detection method for Java software project dependent conflict semantic consistency |
Non-Patent Citations (1)
| Title |
|---|
| 基于依赖关系的软件需求建模与优先级评估方法研究;邵飞;《中国博士学位论文全文数据库信息科技辑》(第06期);I138-26 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112965913A (en) | 2021-06-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112965913B (en) | Java software dependency conflict problem automatic repairing method | |
| US11366747B2 (en) | Unified test automation system | |
| US8954930B2 (en) | System and method for reducing test effort by object risk analysis | |
| US10509693B2 (en) | Method for identifying a cause for a failure of a test | |
| Raemaekers et al. | Semantic versioning versus breaking changes: A study of the maven repository | |
| US9880832B2 (en) | Software patch evaluator | |
| CN112181858B (en) | Automatic detection method for Java software project dependent conflict semantic consistency | |
| Artho et al. | Why do software packages conflict? | |
| US10579513B2 (en) | Test run control method and apparatus | |
| US10514898B2 (en) | Method and system to develop, deploy, test, and manage platform-independent software | |
| CN110543427A (en) | Test case storage method and device, electronic equipment and storage medium | |
| CN114756456A (en) | Continuous integration method and device and computer readable storage medium | |
| CN113971031A (en) | Software package dependency relationship checking method and device | |
| Huang et al. | Characterizing and detecting configuration compatibility issues in android apps | |
| CN111240719B (en) | Defect-driven third-party library version upgrade recommendation method | |
| Dann et al. | UPCY: Safely Updating Outdated Dependencies | |
| CN106909434B (en) | Method and device for detecting undefined function in executable program | |
| CN111352631A (en) | Interface compatibility detection method and device | |
| JP2022159035A (en) | Generation of software program repair explanations | |
| CN114816984A (en) | JAVA program regression test method and test device | |
| Artho | Iterative delta debugging | |
| CN115934157B (en) | Automatic software dependency range deducing method, device, computer equipment and memory | |
| CN117311797A (en) | Software library version safety replacement method based on static analysis | |
| Dann | Secure Use of Open-Source Software–A Systematic Study and Techniques for Java | |
| CN118331575A (en) | File conflict processing method, device, equipment and medium |
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 |