我目前正在寻找对现有项目运行静态分析。由于该项目是由一家场外公司创建和提供的,因此我无法从根本上改变构建过程。
该项目分为很多子模块,位于不同的地方。对于其他分析工具(JDepend、Google Testability Explorer 等),我已将所有构建 JAR 文件动态检测到 path
元素中,如下所示:
<path id="built-libs">
<fileset dir="${overall-base}">
<include name="${some-common-base}/**/lib/*.jar" />
</fileset>
</path>
<property name="built-libs-string" refid="built-libs" />
对于某些工具,我使用 build-libs
,对于其他人,我使用字符串(以类路径形式;x.jar;y.jar
)。
问题是,FindBugs 使用与其他格式完全不同的格式;
<class location="x.jar"/>
<class location="y.jar"/>
...
现在,我可以手动列出所有 JAR 文件,但随后会面临此列表与其他工具的列表不同步或引入拼写错误的风险。
另一个复杂之处是我还想在 Jenkins 中运行报告,在这种情况下,各个模块的提取目录将取决于先前构建模块的作业(管道构建、从 SCM 提取并并行构建的模块、报告发生)在管道的末端)。
我可以调用操作系统来运行 FindBugs,在空格分隔的列表中传递 JAR(如 从 Ant 调用 FindBugs:将空格分隔的文件列表传递给 java)。然而,我更喜欢 Ant 解决方案而不是 OS hack。
注意我知道 sourcepath
元素也有类似的问题,但是,我假设解决 class
元素问题也解决了 <代码>源路径一。
I'm currently looking to run static analysis over a pre-existing project. As the project is created and supplied by an off-site company, I cannot change the build process radically.
The project is split into a lot of sub-modules, located in various places. For other analyisi tools (JDepend, Google Testability Explorer, etc.), I have dynamically detected all build JAR files into a path
element as follows:
<path id="built-libs">
<fileset dir="${overall-base}">
<include name="${some-common-base}/**/lib/*.jar" />
</fileset>
</path>
<property name="built-libs-string" refid="built-libs" />
For some tools, I use the build-libs
, for others I use the string (in classpath form; x.jar;y.jar
).
The trouble is, FindBugs uses a completely different format to any other;
<class location="x.jar"/>
<class location="y.jar"/>
...
Now, I could list all the JAR files manually, but then run the risk of this list going out of synch with the other tool's lists, or of introducing typos.
Another complication is that I also want to run the reports in Jenkins, in this case the extract directory for individual modules will depend on the job that has previously built the module (pipeline builds, modules extracted from SCM and built in parallel, the reporting occurring at the end of the pipline).
I could make a call out to the OS to run FindBugs, passing in the JARs in a space separated list (as in Invoking FindBugs from Ant: passing a space-separated list of files to java). However, I prefer a, Ant solution to an OS <exec...
hack.
Note I know I have a similar problem for the sourcepath
element, however, I'm assuming that solving the class
element problem also solves the sourcepath
one.
发布评论
评论(2)
理想情况下,FindBugs 应该采用资源集合,而不是单独的
类
元素。我不熟悉 FindBugs,所以我无法评论为什么他们选择使用class
元素路由而不是资源集合,但是您对使用exec
意味着使用资源集合是一种有效的设计替代方案。我会尝试滚动您自己的 Ant 宏,其中 使用 href="http://ant.apache.org/manual/Tasks/java.html" rel="nofollow">java 任务。这应该为您提供所需的控制,并避免 FindBugs Ant 任务引入的冗余。
另一种选择(这是一个丑陋的黑客)是使用
fileset
编写一个带有 FindBugs 目标的迷你 ant 文件,然后使用 ant 任务。 颤抖Ideally, FindBugs should be taking a resource collection rather than separate
class
elements. I'm not familiar with FindBugs, so I can't comment on why they have chose to go theclass
element route instead of a resource collection, however your comment about usingexec
implies that using a resource collection is a valid design alternative.I would try rolling your own Ant macro, which invokes FindBugs directly using the java task. This should give you the control you need and avoiding the redundancy that the FindBugs Ant task would introduce.
Another option (which is an ugly hack) is to use the
fileset
to write a mini ant file with a FindBugs target, which you then invoke using the ant task. shuddersFindbugs Ant 任务允许您指定可用于指定多个文件的文件列表。引用自 Findbugs 文档
包含 ${lib.dir} 处所有 jar 的示例:
The Findbugs Ant task allows you to specify a filelist which can be used to specify multiple files. Quoting from the Findbugs documentation
Example that includes all jars at ${lib.dir}: