【问题标题】:Sonar warnings due to unresolvable dependencies由于无法解决的依赖关系导致的声纳警告
【发布时间】:2013-02-22 10:55:27
【问题描述】:

我们的项目是一个使用 maven 构建的多模块插件项目。声纳分析运行良好,但在此过程中会产生大量警告,并且可能会产生不正确的结果。下面是项目的设置和分析过程中产生的警告。非常感谢您在修复这些警告方面的任何帮助。

项目设置:

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

以下属性在声纳分析期间提供给 Jenkins 中的声纳插件。

-Dsonar.profile="我的项目资料" -Dsonar.dynamicAnalysis=reuseReports -Dsonar.core.codeCoveragePlugin=jacoco -Dsonar.jacoco.reportPath=../../releng/com.mycompany.myproject.releng.builds/coverage_data/jacoco.exec

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

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

  1. 在对单个模块进行声纳分析之前,会引发以下错误。
[警告] 在构建的这一点上无法解决以下依赖项,但似乎是反应器的一部分: 15:04:52 [警告] o com.mycompany.myproject.plugins:com.mycompany.myproject.external.libraries:jar:1.0.0-SNAPSHOT(提供) 15:04:52 [警告]尝试将构建运行到生命周期阶段“包” 15:04:52 [警告] 在构建的这一点上无法解决以下依赖关系,但似乎是反应器的一部分: 15:04:52 [警告] o com.mycompany.myproject.plugins:com.mycompany.myproject.somefunctionality.framework:jar:1.0.0-SNAPSHOT(提供)
  1. 在分析模块期间,它会抛出以下警告
类 'com/mycompany/myproject/core/common/datatransfers/MyClass' 不能通过 ClassLoader 访问。 [警告] [15:05:25.731] 类 'com/mycompany/myproject/core/common/datatransfers/MyClass' 无法通过 ClassLoader 访问。
  1. 几乎所有模块在构建完成后分析后都标记为已跳过,但分析结果在 Sonar 中可用。
[信息] com.mycompany.myproject.platform.feature ...... 跳过 [信息] com.mycompany.myproject.somefeature.feature ...跳过 [信息] 我的产品 ................... 已跳过 [信息] --------------------------------------------- ------------------------- [信息] 构建成功

【问题讨论】:

  • 我们遇到了同样的问题。我想比较环境。您是否使用 JFrog Artifactory 或 Sonatype Nexus 等本地 maven 工件服务器?
  • 您好,我也遇到了同样的问题。你解决了这个错误吗?如果有,请告诉我如何解决?

标签: jenkins sonarqube


【解决方案1】:

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

【讨论】:

  • 嗨,你确定这对你有用吗?除了干净的包只是不将任何插件安装到本地存储库中之外,干净的安装和干净的包不是几乎相同吗?你认为这个错误可能是由于本地 maven repo 中的一些损坏的 JAR 造成的吗?
  • 实际上我通过运行“mvn clean install”解决了这个问题。
【解决方案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-p2acme-p3

Maven 将按以下顺序构建:

  • acme-parent
  • acme-common
  • acme-p1acme-p2acme-p3acme-p4

但是,对于内部机制,那就是另一回事了:

  • acme-p2acme-p3 不在本地存储库中
  • 都在反应堆中
  • acme-p1 中调用插件期间,maven 将验证在反应器中找到的工件并尝试解析本地工件的路径但失败(因此发出警告)。

如果您将acme-p4 移动到acme-p1 之前,则会更改构建顺序:警告消失(注意:需要从本地存储库中删除依赖项)因为现在,acme-p2acme-p3 已有效构建在acme-p1之前。

Maven 将按以下顺序构建:

  • acme-parent
  • acme-common
  • acme-p2acme-p3acme-p4acme-p1

有一些修复:

  • 添加从 acme-p4 到 acme-p1 的依赖项:这将以额外的小心为代价强制构建顺序(在我的实际用例中,acme-p4acme-p2acme-p3 使用 maven-assembly-plugin) .
  • 在 reactor 中重新排序项目:我没有使用 -T 选项进行测试,允许并发构建,但我认为它也可能会失败。
  • 进行package 构建:警告中提到了它,但我怀疑Maven 在某些情况下会引用本地存储库或远程存储库中的工件(如果您在它们上部署SNAPSHOT)。这可能很棘手:如果有人更改方法的签名,那么 Maven 可能会下载 SNAPSHOT(它较新,并且不在反应堆中,因此它比本地 repo 更好)并且构建可能会失败(这是纯粹是我的假设)。

这也可能是 Maven 在反应堆中对模块排序的错误。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2020-12-30
    • 1970-01-01
    • 2016-02-16
    • 2017-02-20
    相关资源
    最近更新 更多