Reports not found in expected directory
Brought to you by:
vlad_r
Menu
▾
▴
#50 Reports not found in expected directory
I'm using EMMA as part of a Netbeans based project
(current versions of Netbeans use an Ant-based project
system). I specified a base coverage directory using
<property name="build.test.coverage.dir"
value="${build.dir}/test/coverage"/>
where ${build.dir} is defined as "build/" and is taken
relative to the project's base directory. Most of the
build runs just fine, the instrumented classes are
output where I expected them in
${build.dir}/test/classes", the metadata and runtime
coverage data are written where expected in
${build.test.coverage.dir}. The coverage report task
finds the source and .emma files just fine, but the
generated reports are written into the directory
D:\Program Files\netbeans-4.1\build\test\coverage\
despite the fact that both the fileset and outfile
parameters are using the same property:
<emma enabled="${emma.enabled}">
<report sourcepath="${src.dir}">
<fileset dir="${build.test.coverage.dir}">
<include name="*.emma"/>
</fileset>
<txt
outfile="${build.test.coverage.dir}/coverage.txt"/>
<html
outfile="${build.test.coverage.dir}/coverage.html"/>
</report>
</emma>
It looks like everything else is correctly taking the
${build.test.coverage.dir} property to be relative to
the Ant script, while the report output takes it
relative to the system's current working directory. In
my opinion this is a bug, it should be relative to the
Ant script same as every other time it's used.
I don't only see this behaviour in Netbeans. If I run
the same build.xml using Ant 1.6.2 at the command line,
but from a different working directory using
D:\>ant -buildfile r:build.xml test
then the coverage reports are written to the D: drive
instead of the R: drive (everything else is written to
R: as expected).
I'm using EMMA 2.0.5312 under Sun's JDK 1.4.2_04 on
Windows NT4.
Logged In: YES
user_id=699270
Originator: NO
I am seeing also this problem with emma 2.1.5320.
I guess the Java classes exposed in the ant API have setters like setOutFile(String x)
To fix the issue, adding new setters taking a File instead of a String as an argument (with the proper processing behind that) would fix the issue. The old setters taking String as an argument should be preserved but marked deprecated.