4
votes

Our project is a multi module plugin project built using maven. The Sonar analysis runs fine but in the process generates a lot of warnings and probably incorrect results. Below is the set up of the project and warnings generated during analysis. Any help in fixing these warnings is highly appreciated.

Project setup:

  1. Sonar analysis via the jenkins build.
  2. Jenkins Sonar plugin is used to run the analysis.
  3. Jenkins and Sonar along with MySQL are running on different machines.

Below properties are provided to Sonar plugin in Jenkins during sonar analysis.


    -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

Below are the warnings generated during analysis:

Note: The below warnings are not generated if Sonar and Jenkins are running in the same machine

  1. Before the Sonar analysis of individual modules the following error is thrown.

    [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. During the analysis of the modules, it throws the following warning

    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. Almost all modules are marked as skipped after the analysis after the build is complete, However the analysis results are available in Sonar.

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

2
We're encountering the same problem. I wanted to compare environments. Do you use a local maven artifacts server like JFrog Artifactory or Sonatype Nexus?buzz3791
Hi I am having the same problem as well. Did you solve this error? If so, please tell me how to solve it?mrQWERTY

2 Answers

1
votes

I know this is a late reply, but I had the same problem and it turned out that I had run mvn clean package instead of mvn clean install. I found this thread on the SonarQube mailing list, hope this helps.

1
votes

This warning may simply due to a race condition in plugins such as maven-jar-plugin (I had the same warning in another Sonar unrelated case with Maven 3.6.3).

Let's consider the following project layout:

  • acme-parent parent for all project
  • acme-aggregator
  • acme-common
  • acme-p1 depends on acme-common
  • acme-p2 depends on acme-common
  • acme-p3 depends on acme-common
  • acme-p4 depends on acme-p2 and acme-p3

Maven will build in this order:

  • acme-parent
  • acme-common
  • acme-p1, acme-p2, acme-p3 and acme-p4

However, for the internal machinery, it is another story:

  • acme-p2 and acme-p3 are not in the local repository
  • all are in the reactor
  • during invocation of a plugin in acme-p1, maven will validate the artifact found in the reactor and will try to resolve path of local artifact but fail (hence the warning).

If you move acme-p4 before acme-p1, this change the build order: the warning goes away (note: the dependencies needs to be removed from local repository) because now, acme-p2 and acme-p3 are effectively built before acme-p1.

Maven will build in this order:

  • acme-parent
  • acme-common
  • acme-p2, acme-p3, acme-p4 and acme-p1

There are some fixes:

  • Adding a dependency from acme-p4 to acme-p1: this will enforce the build order at the cost of extra care (in my real use case, acme-p4 packages acme-p2 and acme-p3 using maven-assembly-plugin).
  • Reorder project in reactor: I did not test that with the -T options, allowing concurrent build, but I think it may also fail.
  • Do a package build: it is mentioned by the warning, but I suspect that Maven will in some case reference an artifact in the local repository or in the remote repository (if you deploy SNAPSHOT on them). This may be tricky: if someone change the signature of a method, then Maven may download the SNAPSHOT (it is newer, and it is NOT in the reactor, therefore it is better than the local repo) and the build may fail (this is purely my hypothesis).

This may also be an error in Maven in how it order module in the reactor.