我们使用SonarQube的最新版本（5）来分析我们的项目。我有一些关于它如何计算目录纠结指数（以前的包裹纠结指数）的问题，我还没有能够找到其他地方的答案。
为什么SonarQube需要访问类文件来计算纠结索引？对于未包含在java文件中的分析，需要哪些信息？
在指定上面的类文件位置时，为什么要提供这样的深层路径？我想指定＆＃34; project.sonar.java.binaries = / path / bin /＆＃34;不是＆＃34; ... = / path / bin / com / company / project / a / b /＆＃34;。我也可以和＃34; ... = / path / bin / ** / * .class＆＃34;或其他一些通配符。为此，我是否需要为项目中的每个包指定单独的类文件位置？我们遇到的问题是我们正在尝试通过自动化流程生成SonarQube配置文件，并向下钻取以找到所有必需的路径是一个问题 - 当流程运行时，无法获得所需的信息。 / p>
为什么当我点击＆＃34;目录纠结索引＆＃34;的链接时，我是否得到一个页面说明＆＃34;没有可用于组件的DSM数据＆＃34;？我在某处读到，对于复杂的项目，SonarQube无法提供有关哪些目录纠结的信息。为什么不？或者问题是我们只为每个项目指定一个类文件路径，而不是列出所有单独的子目录？
纠结索引听起来很有意思，但是如果我不能深入了解哪些包显示纠结，那么它将无法帮助我们改进代码。
答案 0 :(得分：1)
因此，该问题实际上有三个问题：
这主要是由于历史原因。 Java分析器中的语义分析是最近的，之前很难100％确定类中引用的类型（让我们说没有工具可以利用数据）。所以解决方案是依靠对字节码的分析。
sonar.java.binaries需要指向包含.class文件的目录，但是它应该位于根包中，因为查找类将在假设包中完成是属性中指定的目录之一的目录。 （因此，如果sonar.java.binaries被定义为指向path/bin，则对于课程com.mycompany.A，我们会查找path/bin/com/mycompany/A.class文件。
这需要更多信息才能提供详细信息。 （就像你的陈述的来源）。