CN112799937B - 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 - Google Patents
基于GitHub自动化检测Maven项目中依赖冲突问题的方法 Download PDFInfo
- Publication number
- CN112799937B CN112799937B CN202110043582.1A CN202110043582A CN112799937B CN 112799937 B CN112799937 B CN 112799937B CN 202110043582 A CN202110043582 A CN 202110043582A CN 112799937 B CN112799937 B CN 112799937B
- Authority
- CN
- China
- Prior art keywords
- conflict
- jar
- dependency
- class
- github
- 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 66
- 230000001419 dependent effect Effects 0.000 claims description 37
- 238000001514 detection method Methods 0.000 claims description 33
- 238000013138 pruning Methods 0.000 claims description 6
- 238000005457 optimization Methods 0.000 claims description 5
- 230000001627 detrimental effect Effects 0.000 claims description 3
- 230000007717 exclusion Effects 0.000 claims description 3
- 238000001914 filtration Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims description 3
- 238000012856 packing Methods 0.000 claims description 3
- 230000007547 defect Effects 0.000 description 3
- 238000007689 inspection Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 239000011148 porous material Substances 0.000 description 1
- 230000003068 static 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/362—Software debugging
- G06F11/3644—Software debugging by instrumenting at runtime
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开一种基于GitHub自动化检测Maven项目中依赖冲突问题的方法，该方法根据造成依赖冲突问题的不同原因将依赖冲突问题分为了三种不同类型的场景，本发明可以自动化检测GitHub用户的由Maven管理的Java程序中是否存在上述三种不同类型场景的依赖冲突问题，检查完毕后会在issue页面显示检查结果，若发现有害冲突还会给出详细的测试报告以及问题节点的调用信息。本发明的方法还实时监控用户更新代码时是否引入了新的依赖冲突问题。使用本发明可以节省用户自身查找依赖冲突问题的时间，极大地降低了程序中出现xx no found bug的风险，有效地提高了程序的有效性。
Description
技术领域
本发明涉及软件可靠性检测技术领域，尤其涉及一种基于GitHub自动化检测Maven项目中依赖冲突问题的方法。
背景技术
软件开发过程中经常会复用第三方开源项目从而减少开发成本。Maven，Apache开发维护的Java项目依赖管理工具。由Maven管理的Java项目可以通过xml形式的pom文件引入并管理第三方依赖组件。然而，由于同一个第三方库存在多个不同的版本以及Maven依赖组件加载的仲裁机制，经常会出现依赖冲突问题，产生软件缺陷，降低软件质量。在测试用例不够完善，测试不够充分的情况下，这种软件缺陷通常会在程序运行时产生xx no foundbu g。Bug的主要类型包括java.lang.NoSuchMethodError、java.lang.NoSuchMethodException和java.lang.ClassNotFoundException。
Java语言的流行也带来了大量的第三方开源库的发展，Maven仓库中涵盖了超过一百万个Java项目，其中包括了超过五百万个不同版本的Jar，这些不同的Jar提供了多种功能供开发者使用。此外，当宿主项目依赖于某一个版本的Jar时，还会引入该Jar对应的依赖组件，平均一个由Maven管理的Java项目会引入48个直接依赖和间接依赖。当一个项目引入了同一个开源项目的不同版本时，就有可能出现依赖冲突问题，产生软件缺陷。然而，Maven对这种依赖冲突问题并没有提供理想的解决方案，只能粗粒度的提示有问题的Jar。
发明内容
针对上述现有技术的不足，本发明提供一种基于GitHub自动化检测Maven项目中依赖冲突问题的方法。GitHub是通过Git进行版本控制的软件源代码托管服务平台，是最流行的Git访问站点。除了允许个人和组织创建和访问保管中的代码以外，它也提供了一些方便社会化共同软件开发的功能，即一般的社区功能，包括允许用户追踪其他用户、组织、软件库的动态，对软件代码的改动和bug提出评论等。目前GitHub拥有超过4000万用户和超过1.9亿的储存库，其中包含了大量由Maven管理的Java项目。
为解决上述技术问题，本发明所采取的技术方案是：一种基于GitHub自动化检测Maven项目中依赖冲突问题的方法，包括如下步骤：
步骤1：用户订阅GitHub Bot，并选择对应的储存库；
步骤2：获取Maven项目中所有的开源依赖组件，所有开源依赖组件的坐标使用组标签GroupId，构建标签ArtifactId和版本Version三个字段进行唯一标识；
步骤3：将依赖冲突问题分为三种不同类型的场景，分别为：
场景一：包粒度的冲突，即同一Jar的不同版本导致的依赖冲突问题；
场景二：类粒度的冲突，即不同Jar包含了完全限定名相同的类；
场景三：宿主项目和第三方Jar中包含冲突的类文件；
步骤4：识别Maven项目中是否包含场景一的依赖冲突问题，过程如下：
步骤4.1：遍历所有依赖冲突，识别出当前项目使用的依赖组件UsedJar，以及未使用的依赖组件集合NotUsedJarSet；
步骤4.2：获得当前项目使用的依赖组件UsedJar中的类集合UsedJarClassSet以及方法集合；获得未使用的依赖组件集合NotUsedJarSet中的类集合NotUsedJarClassSet以及方法集合；通过比较UsedJarClassSet和NotUsedJarClassSet中方法的差异以及判断是否被宿主项目调用得到风险方法集合riskMethods；
采用soot对所述依赖组件UsedJar和所述未使用的依赖组件集合NotUsedJarSet进行解析，过程如下：
步骤4.2.1：在soot分析阶段，使用剪枝策略来加快分析速度；所述Soot是一个Java优化框架，可以使用soot来分析、检测Java程序。
步骤4.2.2：项目初始化时，建立全局依赖树，检测每一个依赖节点是否在声明时使用exclusion强制排除了某些节点，将依赖树检测结果存入字典中；其中，键是被排除的结点，值是排除它的结点的集合；
步骤4.2.3：分析冲突时，首先向soot中加载当前依赖冲突节点调用路径上的所有父节点；其次，扫描字典，若字典的键中包含当前冲突调用路径上的结点，则将排除它的结点的调用路径也加入进来；
步骤4.2.4：通过以上的剪枝优化策略，可以有效的加快程序运行速度，减少程序运行时所需JVM内存的大小。
步骤4.3：若风险方法集合riskMethods为空则表示这是一个无害的依赖冲突，若风险方法集合riskMethods不为空则表示这是一个有害的依赖冲突，需要引起开发者的重视。
步骤5：识别Maven项目中是否包含场景二的依赖冲突问题，过程如下：
步骤5.1：首先确定该场景下是否有类的丢失，若有包级别的依赖冲突问题时，会带来类的丢失；
步骤5.2：当有类的丢失时，首先遍历所有的风险Jar集合JarRisks，找到不同的Jar中包含完全限定名相同的类，两两组合构成“包含重复类的Jar对”DupClsJarPair，储存到集合container中，并过滤掉“包含重复类的Jar对”DupClsJarPair中两个“依赖Jar”DepJar拥有相同组标签GroupId、构建标签ArtifactId、版本Version和标识符classifier的；
步骤5.3：遍历集合container，对每一个“包含重复类的Jar对”DupClsJarPair提取两个Jar的“依赖Jar”DepJar存入储存器classDupRiskMemoryUnit中，并且根据依赖树路径确定“包含重复类的Jar对”DupClsJarPair中“依赖Jar”DepJar的优先级从而确定是哪一个Jar被调用；
步骤5.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
步骤6：识别Maven项目中是否包含场景三的依赖冲突问题，过程如下：
步骤6.1：明确该场景问题产生的原因：若将自身项目与第三方一同打包成Jar时，第三方包中的同名类会被加载；自身项目与第三方分别打包发布，在运行时实际加载的是宿主项目中的同名类；
步骤6.2：遍历自身项目与第三方项目，找到自身项目与第三方项目中包含完全限定名相同的类；
步骤6.3：根据配置文件pom.xml中对于打包方式的定义来得出具体是哪个Jar被加载；
步骤6.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
步骤7：以GitHub issue的形式将检测结果反馈给用户，过程如下：
步骤7.1：读取检测结果，封装成markDown格式的文本；文本中包括项目名，冲突的包名，以及冲突的包被加载和被屏蔽的信息，冲突方法riskMethod的调用路径和项目的依赖树；
步骤7.2：将文本提交成issue，并且在issue名称后打上dependency-conflict的标签，便于用户区分查看。
步骤8：当用户对储存库代码进行更新时，Bot自动检测是否引入了新的依赖冲突问题，并给出说明，过程如下：
步骤8.1：获取用户新提交的代码；
步骤8.2：与上一版本的代码中的pom文件进行对比，通过对比每一个依赖项得出本次更新的Jar集合needReDetects；
步骤8.3：对于得到的集合needReDetects中的每一个节点needReDetectSig进行单独的依赖冲突检查而不是全盘依赖冲突检查，从而加快检测速度；
步骤8.4：若检查无误则会在Github issue页面中显示测试成功，若检查时发现有害冲突，则在Github issue页面中显示发现有害冲突，并给出检测报告。
所述检测报告包含项目名，冲突的包名，被加载的包的信息，被屏蔽的包的信息，冲突方法riskMethod的调用路径，和项目的依赖树。
步骤9：用户根据需要选择增加储存库，或者不再订阅该app。
采用上述技术方案所产生的有益效果在于：
1、本发明提供的方法将依赖冲突问题分为三种不同类型的场景，对这三种场景进行检测，克服了现有技术对依赖冲突粗粒度的检测手段的不足。
2、本发明可以监控三种场景下的依赖冲突问题，不仅更全面地对Maven项目中的依赖冲突问题进行检测，还可以生成更详细的检测报告，使得开发者可以更快速、更容易地检测程序中的依赖冲突问题。避免了一味地为开发者报警所有的依赖冲突问题，从而产生大量无用的信息，增加开发者的负担，使开发者忽略真正的bug。
3、本发明将GitHub作为载体，可以让GitHub用户更方便，更自动化地监控自身项目中的依赖冲突问题，极大地减少开发人员处理依赖冲突问题的时间，使得程序质量更高。
4、本发明在Github用户更新储存库代码时，可以实时地检测用户更新的代码中是否引入了新的依赖冲突问题。在对用户更新的代码进行依赖冲突检测时，只会检测改动的依赖组件节点而不是对所有的依赖组件节点都进行检查，从而有效的加快检测速度。检查完毕后会在issue页面显示检查结果，若发现有害冲突还会给出详细的测试报告以及问题节点的调用信息。
附图说明
图1为本发明实施例中基于GitHub自动化检测Maven项目中依赖冲突问题的方法流程图；
图2为本发明实施例中检测三种场景的依赖冲突问题的流程图。
具体实施方式
下面结合附图和实施例，对本发明的具体实施方式作进一步详细描述。以下实施例用于说明本发明，但不用来限制本发明的范围。
如图1所示，本实施例中基于GitHub自动化检测Maven项目中依赖冲突问题的方法如下所述：
步骤1：用户订阅GitHub Bot，并选择对应的储存库；
如图1所示，GitHub用户在GitHub Marketplace中订阅该Bot，并选择相应的储存库，此时Bot会将用户选择的储存库克隆下来并编译成二进制文件，以便后续静态分析工具soot使用。
步骤2：获取Maven项目中所有的开源依赖组件，所有开源依赖组件的坐标使用组标签GroupId，构建标签ArtifactId和版本Version三个字段进行唯一标识；
若两个Jar的组标签GroupId和构建标签ArtifactId相同则属于同一个第三方库，如果项目的依赖树中出现了两个及以上属于同一个第三方库，但版本不同的Jar，那么这就产生了一个依赖冲突。
对于Maven项目而言，项目依赖组件分为直接依赖和间接依赖，直接依赖是显式声明在pom文件中的，间接依赖是写在直接依赖的pom文件中或者是直接依赖在运行时需要的依赖组件。使用api接口dependencyTreeBuilder建立分析树，树根为root。使用Maven的api接口，在DependencyNodeVisitor中实现visit接口，在visit接口中实现了相关的依赖组件加载逻辑，使用“先序遍历”，遍历树中的每一个依赖组件(直接依赖和间接依赖)。
步骤3：将依赖冲突问题分为三种不同类型的场景，分别为：
场景一：包粒度的冲突，即同一Jar的不同版本导致的依赖冲突问题；
场景二：类粒度的冲突，即不同Jar包含了完全限定名相同的类；
场景三：宿主项目和第三方Jar中包含冲突的类文件；
步骤4：识别Maven项目中是否包含场景一的依赖冲突问题，过程如下：
步骤4.1：遍历所有依赖冲突，识别出当前项目使用的依赖组件UsedJar，以及未使用的依赖组件集合NotUsedJarSet；在编译阶段，项目中只会加载其中一个版本，这个版本称为被使用的Jar，而其他的版本被称为没有加载的Jar。为了识别出项目中是否包含场景一的依赖冲突问题，需要统计每一个第三方Jar是否有多个版本，如果有两个及以上的版本被引入则需要记录。在这一过程中可以使用接口DependencyNode的状态state进行判断，state为加载INCLUDED的节点为使用的包UsedJar，其余状态的节点为未使用的包NotUsedJar并构成集合NotUsedJarSet。
步骤4.2：获得当前项目使用的依赖组件UsedJar中的类集合UsedJarClassSet以及方法集合；获得未使用的依赖组件集合NotUsedJarSet中的类集合NotUsedJarClassSet以及方法集合；通过比较UsedJarClassSet和NotUsedJarClassSet中方法的差异以及判断是否被宿主项目调用得到风险方法集合riskMethods；
采用soot对所述依赖组件UsedJar和所述未使用的依赖组件集合NotUsedJarSet进行解析，如图2所示，过程如下：
步骤4.2.1：在soot分析阶段，使用剪枝策略来加快分析速度；所述Soot是一个Java优化框架，可以使用soot来分析、检测Java程序。
步骤4.2.2：项目初始化时，建立全局依赖树，检测每一个依赖节点是否在声明时使用exclusion强制排除了某些节点，将依赖树检测结果存入字典中；其中，键是被排除的结点，值是排除它的结点的集合；
步骤4.2.3：分析冲突时，首先向soot中加载当前依赖冲突节点调用路径上的所有父节点；其次，扫描字典，若字典的键中包含当前冲突调用路径上的结点，则将排除它的结点的调用路径也加入进来；
步骤4.2.4：通过以上的剪枝优化策略，可以有效的加快程序运行速度，减少程序运行时所需JVM内存的大小。
步骤4.3：若风险方法集合riskMethods为空则表示这是一个无害的依赖冲突，若风险方法集合riskMethods不为空则表示这是一个有害的依赖冲突，需要引起开发者的重视。
步骤5：识别Maven项目中是否包含场景二的依赖冲突问题，如图2所示，过程如下：
步骤5.1：首先确定该场景下是否有类的丢失，若有包级别的依赖冲突问题时，会带来类的丢失；
步骤5.2：当有类的丢失时，首先遍历所有的风险Jar集合JarRisks，找到不同的Jar中包含完全限定名相同的类，两两组合构成“包含重复类的Jar对”DupClsJarPair，储存到集合container中，并过滤掉“包含重复类的Jar对”DupClsJarPair中两个“依赖Jar”DepJar拥有相同组标签GroupId、构建标签ArtifactId、版本Version和标识符classifier的；
步骤5.3：遍历集合container，对每一个“包含重复类的Jar对”DupClsJarPair提取两个Jar的“依赖Jar”DepJar存入储存器classDupRiskMemoryUnit中，并且根据依赖树路径确定“包含重复类的Jar对”DupClsJarPair中“依赖Jar”DepJar的优先级从而确定是哪一个Jar被调用；
步骤5.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
步骤6：识别Maven项目中是否包含场景三的依赖冲突问题，如图2所示，过程如下：
步骤6.1：明确该场景问题产生的原因：若将自身项目与第三方一同打包成Jar时，第三方包中的同名类会被加载；自身项目与第三方分别打包发布，在运行时实际加载的是宿主项目中的同名类；
步骤6.2：遍历自身项目与第三方项目，找到自身项目与第三方项目中包含完全限定名相同的类；
步骤6.3：根据配置文件pom.xml中对于打包方式的定义来得出具体是哪个Jar被加载；
步骤6.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
步骤7：以GitHub issue的形式将检测结果反馈给用户，过程如下：
步骤7.1：读取检测结果，封装成markDown格式的文本；文本中包括项目名，冲突的包名，以及冲突的包被加载和被屏蔽的信息，冲突方法riskMethod的调用路径和项目的依赖树；
步骤7.2：将文本提交成issue，并且在issue名称后打上dependency-conflict的标签，便于用户区分查看。
步骤8：当用户对储存库代码进行更新时，Bot自动检测是否引入了新的依赖冲突问题，并给出说明，过程如下：
步骤8.1：获取用户新提交的代码；
步骤8.2：与上一版本的代码中的pom文件进行对比，通过对比每一个依赖项得出本次更新的Jar集合needReDetects；
步骤8.3：对于得到的集合needReDetects中的每一个节点needReDetectSig进行单独的依赖冲突检查而不是全盘依赖冲突检查，从而加快检测速度；这些被忽略掉的冲突节点是已经检查完毕的。这里只会关注有变动的冲突节点，从而加快程序运行速度。
步骤8.4：若检查无误则会在Github issue页面中显示测试成功，若检查时发现有害冲突，则在Github issue页面中显示发现有害冲突，并给出检测报告。
所述检测报告包含项目名，冲突的包名，被加载的包的信息，被屏蔽的包的信息，冲突方法riskMethod的调用路径，和项目的依赖树。
步骤9：用户根据需要选择增加储存库，或者不再订阅该app，如图1所示，过程如下：
步骤9.1：当用户选择增加储存库时，本方法跳转至步骤4，对用户增加的储存库进行三个场景下的依赖冲突检查，并以GitHub issue的形式将检测结果反馈给用户；
步骤9.2：当用户不再订阅该app时，app将从用户的储存库中卸载。
Claims (8)
1.一种基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，包括如下步骤：
步骤1：用户订阅GitHub Bot，并选择对应的储存库；
步骤2：获取Maven项目中所有的开源依赖组件，所有开源依赖组件的坐标使用组标签GroupId，构建标签ArtifactId和版本Version三个字段进行唯一标识；
步骤3：将依赖冲突问题分为三种不同类型的场景，分别为：
场景一：包粒度的冲突，即同一Jar的不同版本导致的依赖冲突问题；
场景二：类粒度的冲突，即不同Jar包含了完全限定名相同的类；
场景三：宿主项目和第三方Jar中包含冲突的类文件；
步骤4：识别Maven项目中是否包含场景一的依赖冲突问题；
步骤5：识别Maven项目中是否包含场景二的依赖冲突问题；
步骤6：识别Maven项目中是否包含场景三的依赖冲突问题；
步骤7：以GitHub issue的形式将检测结果反馈给用户；
步骤8：当用户对储存库代码进行更新时，Bot自动检测是否引入了新的依赖冲突问题，并给出说明；
步骤9：用户根据需要选择增加储存库，或者不再订阅GitHub Bot。
2.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述步骤4的过程如下：
步骤4.1：遍历所有依赖冲突，识别出当前项目使用的依赖组件UsedJar，以及未使用的依赖组件集合NotUsedJarSet；
步骤4.2：获得当前项目使用的依赖组件UsedJar中的类集合UsedJarClassSet以及方法集合；获得未使用的依赖组件集合NotUsedJarSet中的类集合NotUsedJarClassSet以及方法集合；通过比较UsedJarClassSet和NotUsedJarClassSet中方法的差异以及判断是否被宿主项目调用得到风险方法集合riskMethods；
步骤4.3：若风险方法集合riskMethods为空则表示这是一个无害的依赖冲突，若风险方法集合riskMethods不为空则表示这是一个有害的依赖冲突，需要引起开发者的重视。
3.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，步骤4.2中采用soot对依赖组件UsedJar和未使用的依赖组件集合NotUsedJarSet进行解析，过程如下：
步骤4.2.1：在soot分析阶段，使用剪枝策略来加快分析速度；
步骤4.2.2：项目初始化时，建立全局依赖树，检测每一个依赖节点是否在声明时使用exclusion强制排除了某些节点，将依赖树检测结果存入字典中；其中，键是被排除的结点，值是排除它的结点的集合；
步骤4.2.3：分析冲突时，首先向soot中加载当前依赖冲突节点调用路径上的所有父节点；其次，扫描字典，若字典的键中包含当前冲突调用路径上的结点，则将排除它的结点的调用路径也加入进来；
步骤4.2.4：通过以上的剪枝优化策略，可以有效的加快程序运行速度，减少程序运行时所需JVM内存的大小。
4.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述步骤5的过程如下：
步骤5.1：首先确定该场景下是否有类的丢失，若有包级别的依赖冲突问题时，会带来类的丢失；
步骤5.2：当有类的丢失时，首先遍历所有的风险Jar集合JarRisks，找到不同的Jar中包含完全限定名相同的类，两两组合构成“包含重复类的Jar对”DupClsJarPair，储存到集合container中，并过滤掉“包含重复类的Jar对”DupClsJarPair中两个“依赖Jar”DepJar拥有相同组标签GroupId、构建标签ArtifactId、版本Version和标识符classifier的；
步骤5.3：遍历集合container，对每一个“包含重复类的Jar对”DupClsJarPair提取两个Jar的“依赖Jar”DepJar存入储存器classDupRiskMemoryUnit中，并且根据依赖树路径确定“包含重复类的Jar对”DupClsJarPair中“依赖Jar”DepJar的优先级从而确定是哪一个Jar被调用；
步骤5.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
5.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述步骤6的过程如下：
步骤6.1：明确该场景问题产生的原因：若将自身项目与第三方一同打包成Jar时，第三方包中的同名类会被加载；自身项目与第三方分别打包发布，在运行时实际加载的是宿主项目中的同名类；
步骤6.2：遍历自身项目与第三方项目，找到自身项目与第三方项目中包含完全限定名相同的类；
步骤6.3：根据配置文件pom.xml中对于打包方式的定义来得出具体是哪个Jar被加载；
步骤6.4：给出具体的调用信息和没有被调用到的类对应的Jar的详细信息。
6.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述步骤7的过程如下：
步骤7.1：读取检测结果，封装成markDown格式的文本；文本中包括项目名，冲突的包名，以及冲突的包被加载和被屏蔽的信息，冲突方法riskMethod的调用路径和项目的依赖树；
步骤7.2：将文本提交成issue，并且在issue名称后打上dependency-conflict的标签，便于用户区分查看。
7.根据权利要求1所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述步骤8的过程如下：
步骤8.1：获取用户新提交的代码；
步骤8.2：与上一版本的代码中的pom文件进行对比，通过对比每一个依赖项得出本次更新的Jar集合needReDetects；
步骤8.3：对于得到的集合needReDetects中的每一个节点needReDetectSig进行单独的依赖冲突检查而不是全盘依赖冲突检查，从而加快检测速度；
步骤8.4：若检查无误则会在Github issue页面中显示测试成功，若检查时发现有害冲突，则在Github issue页面中显示发现有害冲突，并给出检测报告。
8.根据权利要求7所述的基于GitHub自动化检测Maven项目中依赖冲突问题的方法，其特征在于，所述检测报告包含项目名，冲突的包名，被加载的包的信息，被屏蔽的包的信息，冲突方法riskMethod的调用路径，和项目的依赖树。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110043582.1A CN112799937B (zh) | 2021-01-13 | 2021-01-13 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110043582.1A CN112799937B (zh) | 2021-01-13 | 2021-01-13 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112799937A CN112799937A (zh) | 2021-05-14 |
| CN112799937B true CN112799937B (zh) | 2023-09-26 |
Family
ID=75810590
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110043582.1A Active CN112799937B (zh) | 2021-01-13 | 2021-01-13 | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112799937B (zh) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113741959A (zh) * | 2021-09-17 | 2021-12-03 | 中国银行股份有限公司 | 基于Maven的版本包组包方法及装置 |
| WO2024016729A1 (zh) * | 2022-07-21 | 2024-01-25 | 华为云计算技术有限公司 | 调用冲突的可视化方法及装置 |
| CN116541307B (zh) * | 2023-06-29 | 2023-10-20 | 云筑信息科技(成都)有限公司 | 一种对比pom版本的数据处理方法 |
| CN117573562B (zh) * | 2024-01-15 | 2024-05-28 | 云筑信息科技(成都)有限公司 | 一种对比pom文件不同版本的方法 |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9491238B2 (en) * | 2010-07-22 | 2016-11-08 | Sap Se | Rapid client-side component processing based on component relationships |
| CN108628751A (zh) * | 2018-05-17 | 2018-10-09 | 北京三快在线科技有限公司 | 一种无用依赖项检测方法及装置 |
| WO2018222852A1 (en) * | 2017-05-31 | 2018-12-06 | Shiftleft Inc. | System and method for application security profiling |
| CN108984416A (zh) * | 2018-08-07 | 2018-12-11 | 东北大学 | 一种评估Maven环境中依赖冲突危险级别的方法 |
| CN110083749A (zh) * | 2019-04-11 | 2019-08-02 | 艾伯资讯（深圳）有限公司 | 用于软件快速开发的检索、复用、环境搭建的系统及方法 |
| CN110618931A (zh) * | 2019-08-14 | 2019-12-27 | 重庆金融资产交易所有限责任公司 | 依赖关系检测方法、装置、计算机设备及可读存储介质 |
| CN112181858A (zh) * | 2020-11-09 | 2021-01-05 | 东北大学 | Java软件项目依赖冲突语义一致性的自动化检测方法 |
| CN112214408A (zh) * | 2020-10-12 | 2021-01-12 | 北京字节跳动网络技术有限公司 | 依赖冲突检测方法、装置、电子设备及计算机可读介质 |
-
2021
- 2021-01-13 CN CN202110043582.1A patent/CN112799937B/zh active Active
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9491238B2 (en) * | 2010-07-22 | 2016-11-08 | Sap Se | Rapid client-side component processing based on component relationships |
| WO2018222852A1 (en) * | 2017-05-31 | 2018-12-06 | Shiftleft Inc. | System and method for application security profiling |
| CN108628751A (zh) * | 2018-05-17 | 2018-10-09 | 北京三快在线科技有限公司 | 一种无用依赖项检测方法及装置 |
| CN108984416A (zh) * | 2018-08-07 | 2018-12-11 | 东北大学 | 一种评估Maven环境中依赖冲突危险级别的方法 |
| CN110083749A (zh) * | 2019-04-11 | 2019-08-02 | 艾伯资讯（深圳）有限公司 | 用于软件快速开发的检索、复用、环境搭建的系统及方法 |
| CN110618931A (zh) * | 2019-08-14 | 2019-12-27 | 重庆金融资产交易所有限责任公司 | 依赖关系检测方法、装置、计算机设备及可读存储介质 |
| CN112214408A (zh) * | 2020-10-12 | 2021-01-12 | 北京字节跳动网络技术有限公司 | 依赖冲突检测方法、装置、电子设备及计算机可读介质 |
| CN112181858A (zh) * | 2020-11-09 | 2021-01-05 | 东北大学 | Java软件项目依赖冲突语义一致性的自动化检测方法 |
Non-Patent Citations (3)
| Title |
|---|
| Riivo Kikas 等.Structure and Evolution of Package Dependency Networks.《2017 IEEE/ACM 14th International Conference on Mining Software Repositories (MSR)》.2017,102-112. * |
| 杨程 等.基于多维特征的开源项目个性化推荐方法.《软件学报》.2017,第28卷(第6期),1357-1372. * |
| 王莹 等.复杂软件系统的重构技术：现状、问题与展望.《计算机科学》.2020,第47卷(第12期),1-10. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112799937A (zh) | 2021-05-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112799937B (zh) | 基于GitHub自动化检测Maven项目中依赖冲突问题的方法 | |
| US10698682B1 (en) | Computerized software development environment with a software database containing atomic expressions | |
| US9430224B2 (en) | Hot-update method and apparatus | |
| Dietrich et al. | Broken promises: An empirical study into evolution problems in java programs caused by library upgrades | |
| US8312440B2 (en) | Method, computer program product, and hardware product for providing program individuality analysis for source code programs | |
| US8434054B2 (en) | System and method for managing cross project dependencies at development time | |
| CN109033843B (zh) | 用于分布式静态检测系统的Java文件依赖性分析方法及模块 | |
| Jezek et al. | How java apis break–an empirical study | |
| US20230244465A1 (en) | Systems and methods for automated retrofitting of customized code objects | |
| CN112394942B (zh) | 基于云计算的分布式软件开发编译方法及软件开发平台 | |
| US20200183818A1 (en) | Detection and correction of coding errors in software development | |
| US20080082974A1 (en) | Managing Software Component Version Identifications in a Componentised Software System | |
| CN111796831B (zh) | 一种多芯片兼容的编译方法和装置 | |
| CN1981266A (zh) | 为优化的程序生成展开信息 | |
| CN112181858B (zh) | Java软件项目依赖冲突语义一致性的自动化检测方法 | |
| US8478953B2 (en) | Buffer snapshots from unmodifiable data piece tables | |
| CN112860312A (zh) | 项目依赖关系变化的检测方法及装置 | |
| CN114138281A (zh) | 软件工程的编译方法、装置、设备及介质 | |
| CN109388568B (zh) | 代码测试方法和装置 | |
| CN112000367B (zh) | 一种二进制库文件版本兼容性识别方法和装置 | |
| CN111352631A (zh) | 一种接口兼容性检测方法及装置 | |
| CN111930387B (zh) | 一种集成包的集成方法及装置、电子设备和存储介质 | |
| CN115292203A (zh) | 一种源代码分析方法及装置 | |
| CN114489653A (zh) | 基于编译器的数据处理方法、装置以及可读存储介质 | |
| US20120330878A1 (en) | Conventions for inferring data models |
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 |