由于无法解析的依赖性导致的声纳警告

Question

我们的项目是使用maven构建的多模块插件项目。声纳分析运行正常，但在此过程中会产生大量警告，可能会产生不正确的结果。以下是分析期间生成的项目和警告的设置。任何有关修复这些警告的帮助都非常感谢。

项目设置：

1. 通过jenkins构建进行声纳分析。
2. Jenkins Sonar插件用于运行分析。
3. Jenkins和Sonar以及MySQL正在不同的机器上运行。

在声纳分析期间，Jenkins的Sonar插件提供了以下属性。

    -Dsonar.profile="My Project Profile"
    -Dsonar.dynamicAnalysis=reuseReports
    -Dsonar.core.codeCoveragePlugin=jacoco
    -Dsonar.jacoco.reportPath=../../releng/com.mycompany.myproject.releng.builds/coverage_data/jacoco.exec

以下是分析过程中产生的警告：

注意：如果Sonar和Jenkins在同一台机器上运行，则不会生成以下警告

1. 在对各个模块进行声纳分析之前，会抛出以下错误。

    [WARNING] The following dependencies could not be resolved at this point of the build but seem to be part of the reactor:
    15:04:52 [WARNING] o com.mycompany.myproject.plugins:com.mycompany.myproject.external.libraries:jar:1.0.0-SNAPSHOT (provided)
    15:04:52 [WARNING] Try running the build up to the lifecycle phase "package"
    15:04:52 [WARNING] The following dependencies could not be resolved at this point of the build but seem to be part of the reactor:
    15:04:52 [WARNING] o com.mycompany.myproject.plugins:com.mycompany.myproject.somefunctionality.framework:jar:1.0.0-SNAPSHOT (provided)

 

1. 在分析模块期间，它会抛出以下警告

    Class 'com/mycompany/myproject/core/common/datatransfers/MyClass' is not accessible through the ClassLoader.
    [WARN] [15:05:25.731] Class 'com/mycompany/myproject/core/common/datatransfers/MyClass' is not accessible through the ClassLoader.

1. 在构建完成后，几乎所有模块都在分析后被标记为跳过，但分析结果可在Sonar中找到。

    [INFO] com.mycompany.myproject.platform.feature ................ SKIPPED
    [INFO] com.mycompany.myproject.somefeature.feature ... SKIPPED
    [INFO] My Product ............................... SKIPPED
    [INFO] ------------------------------------------------------------------------
    [INFO] BUILD SUCCESS

Answer 1

我知道这是一个迟到的回复，但我遇到了同样的问题，结果发现我已经运行了mvn clean package而不是mvn clean install。我在SonarQube邮件列表上找到this thread，希望这有帮助。

Answer 2

此警告可能仅仅是由于maven-jar-plugin之类的插件中的竞争状况引起的（在另一个与Maven 3.6.3无关的Sonar案例中，我也有相同的警告）。

让我们考虑以下项目布局：

所有项目的
• acme-parent父级
• acme-aggregator
• acme-common
• acme-p1取决于acme-common
• acme-p2取决于acme-common
• acme-p3取决于acme-common
• acme-p4取决于acme-p2和acme-p3

Maven将按以下顺序构建：

• acme-parent
• acme-common
• acme-p1，acme-p2，acme-p3和acme-p4

但是，对于内部机制，这是另一个故事：

• acme-p2和acme-p3不在本地存储库中
• 所有人都在反应堆中
• 在acme-p1中调用插件期间，maven将验证在反应堆中找到的工件，并尝试解析本地工件的路径，但会失败（因此出现警告）。

如果将acme-p4移到acme-p1之前，这会更改构建顺序：警告消失了（注意：需要从本地存储库中删除依赖项），因为现在acme-p2和acme-p3实际上是在acme-p1之前构建的。

Maven将按以下顺序构建：

• acme-parent
• acme-common
• acme-p2，acme-p3，acme-p4和acme-p1

有一些修复程序：

• 从acme-p4到acme-p1添加一个依赖项：这将以额外的照顾为代价来强制执行构建顺序（在我的实际用例中，acme-p4包acme-p2和{{1} }，使用acme-p3。
• 对反应堆中的项目进行重新排序：我没有使用maven-assembly-plugin选项进行测试，允许并发构建，但是我认为它可能也会失败。
• 执行-T构建：警告中提到了该构建，但是我怀疑Maven在某些情况下会引用本地存储库或远程存储库中的工件（如果您将package部署在他们）。这可能很棘手：如果有人更改了方法的签名，那么Maven可能会下载SNAPSHOT（它是更新的，并且不在反应堆中，因此比本地仓库要好），并且构建可能会失败（这是纯粹是我的假设。

这也可能是Maven如何订购反应堆中模块的错误。