SonarQube Eclipse
  1. SonarQube Eclipse
  2. SONARIDE-221

Classpath loader does not include project dependencies

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 3.0
    • Component/s: Local Mode
    • Labels:
      None
    • Environment:
      Ubuntu 8.10
    • Number of attachments :
      1

      Description

      I've got this warning for project dependencies of the analyzed project (local analyses) :

      [WARN] Unhandled ClassPathEntry
      [WARN] Class '**************' is not accessible through the ClassLoader.

      With m2eclipse, jar dependencies are declared as project dependencies when
      the project of the dependency is opened inside the workspace.

      Related discussion in ML : http://markmail.org/message/vlrfyhlcpavmk5mv

        Issue Links

          Activity

          Hide
          Ronald Brindl added a comment -

          I also ran into this problem.
          IClasspathEntry of kind CPE_PROJECT is not handled.
          I added a switch-case for this which iterates over the dependent projects recursively and adds their output path(s) and their library dependencies, but not their source folders (only output-folders for source-folders), to avoid having analyzed all those other projects, too.
          It does not handle any access rules, but i think these can be ommited safely for analyzing purposes.

          My patch by the way also fixes an issue, that project-local library references are not resolved correctly.
          eg. project A references a library x.jar within project A's lib folder.
          This currently gets resolved to "/A/lib/x.jar".
          I added a project and workspace lookup which tries to find the library within project or workspace and returns the path to that member. This can then be resolved to an absolute filesystem path.
          I don't know if there is a simpler way to do that.
          I tested my changes with our production setup, which contains around 60 OSGI projects and lots of third party libs. I think this covers about every possible setup you can imagine

          Show
          Ronald Brindl added a comment - I also ran into this problem. IClasspathEntry of kind CPE_PROJECT is not handled. I added a switch-case for this which iterates over the dependent projects recursively and adds their output path(s) and their library dependencies, but not their source folders (only output-folders for source-folders), to avoid having analyzed all those other projects, too. It does not handle any access rules, but i think these can be ommited safely for analyzing purposes. My patch by the way also fixes an issue, that project-local library references are not resolved correctly. eg. project A references a library x.jar within project A's lib folder. This currently gets resolved to "/A/lib/x.jar". I added a project and workspace lookup which tries to find the library within project or workspace and returns the path to that member. This can then be resolved to an absolute filesystem path. I don't know if there is a simpler way to do that. I tested my changes with our production setup, which contains around 60 OSGI projects and lots of third party libs. I think this covers about every possible setup you can imagine
          Hide
          Evgeny Mandrikov added a comment -

          Hi Ronald,
          FYI: patch was applied in separate branch - https://github.com/Godin/sonar-eclipse/tree/SONARIDE-221 for future review and merge to master.
          Thanks for your contribution.

          Show
          Evgeny Mandrikov added a comment - Hi Ronald, FYI: patch was applied in separate branch - https://github.com/Godin/sonar-eclipse/tree/SONARIDE-221 for future review and merge to master. Thanks for your contribution.
          Hide
          Evgeny Mandrikov added a comment -

          One of the problems with this patch - same JAR library used in different projects would be added several times. For example JRE libraries for different projects would be added several times. Also interesting case if different JREs used in different projects.

          Show
          Evgeny Mandrikov added a comment - One of the problems with this patch - same JAR library used in different projects would be added several times. For example JRE libraries for different projects would be added several times. Also interesting case if different JREs used in different projects.
          Hide
          Ronald Brindl added a comment -

          We do have some projects with 1.5 JDK, and even one with 1.4, whereas most projects use java 6. I did not see any trouble here, but i only tried analyzing java-6 projects that use projects with java-1.5, not the other way round. I guess that would not work.
          Since the classes are compiled by eclipse, i suppose it takes the correct compiler and my patch uses the compiled classes. As long as the jdk used to executes sonar/findbugs/pmd etc is compatible with the classes, this should work.
          But you are right, the JDK classes should only be added once (only those of the project the analysis was started with).

          Show
          Ronald Brindl added a comment - We do have some projects with 1.5 JDK, and even one with 1.4, whereas most projects use java 6. I did not see any trouble here, but i only tried analyzing java-6 projects that use projects with java-1.5, not the other way round. I guess that would not work. Since the classes are compiled by eclipse, i suppose it takes the correct compiler and my patch uses the compiled classes. As long as the jdk used to executes sonar/findbugs/pmd etc is compatible with the classes, this should work. But you are right, the JDK classes should only be added once (only those of the project the analysis was started with).
          Hide
          Julien HENRY added a comment -

          Fixed by applying the patch with a simple improvement: for dependent projects libraries that are not exported will not be added to the classpath.
          Thanks for your contribution.

          Show
          Julien HENRY added a comment - Fixed by applying the patch with a simple improvement: for dependent projects libraries that are not exported will not be added to the classpath. Thanks for your contribution.
          Hide
          Freddy Mallet added a comment -

          Manually tested !

          Show
          Freddy Mallet added a comment - Manually tested !

            People

            • Assignee:
              Julien HENRY
              Reporter:
              Michenaud Laurent
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: