Hello,
I use ant to run emma and everything works fine. My only problem isthat I get the reports at a location relative to user.dir. I tried the property 'coverage.out.file', at several places, but my reports still show up relative to user.dir. Does anyone have a tip? Perhaps a segment of an ant build file?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As documented, 'coverage.out.file' sets the location of the coverage dump file (*.ec), not the report location.
If you are using ANT, the easiest way to set the report locations is to use 'outfile' attributes on <html>, <txt>, <xml> report configurator elements (nested inside <report>.
I could give you a snippet from build.xml that I am using right now at work, but to be honest it is identical to one of the examples in the reference manual (http://emma.sourceforge.net/reference/ch02s04s02.html):
<html outfile="${coverage.dir}/coverage.html"
depth="method"
columns="name,class,method,block,line"
/>
(${coverage.dir} is set to a custom dir in my project)
ANT usage sections in the reference manual for each of EMMA tools has real-life examples (that is, they were tested in real build.xml files and then pasted into the docs). I recommend you check that content out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the reply, I am now a step further.
I wanted to create the reports in a directory from the root of the drive. We develop with a group and some have their source files on the C: drive and some on the D: drive. I wanted to create the reports in /xxx/coverage. I tried the outfile attribute to archieve this (but failed). Then I encountered the coverage.out.file property, but misinterpreted it. Now I verified that if I specify a complete path like c:/xxx/coverage, the reports will be generated there.
Still, it would be nice if I could specify the location /xxx/coverage instead of c:/xxx/coverage. Now half my group of developers must modify the build file and change c: to d:. Do you think I should file a change request for this? If you have other tips, please let me know.
Thanks, Rene Engbers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe the issue may be caused by the exact interpretation of a pathname starting with a "/" (specifically, whether such a pathname is absolute or relative). Not only is this different on win32 and UNIX platforms, ANT task attributes that are file descriptors are massaged by ANT before they are passed into tasks and this processing may not always be correct. The latter is not something EMMA can do much about.
I have a couple of suggestions:
(a) Isn't it easier to create build artifacts (including coverage reports) relative to your build's ${basedir} in the first place? When I design ANT builds, I make everything relative to ${basedir}, period. This makes an ANT build completely absolute disk position-independent and is definitely the way to go.
You seem to be doing almost the same thing (build is independent of whether it is on c: or on d:), I am just asking you to consider the next logical step. I am routinely involved in team projects and in fact these days the team members use a mix of win32 and Linux platforms. My builds require zero changes between win32 and Linux and on win32 they are completely insensitive to drive/directory location.
(b) I believe it is common to factor out small amount of build customization into a file like build.properties that each team member tweaks to suite their taste. You could make ${coverage.dir} a setting like that (it would be set to c:/... or d:/... etc). This requires one more configuration step before a build is fully functional, but it's a price you pay if you don't go the (a) route.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We only have one agreement regarding directories in our project: results are stored in \xxx\. So our basdir starts with a '\'. For all other tools (java compiler, JUnit) this works. Also Emma has no problem in finding the class files (also relative to our basedir) to instrument. The by Emma instrumented class files are also nicely stored relative to our basedir. The only problem is the report location, somehow now the basedir does not work and the user.dir is used instead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Understood. Thanks for the details. I have added a new bug issue (https://sourceforge.net/tracker/index.php?func=detail&aid=1077741&group_id=108932&atid=651897) for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have analyzed the problem. Looking at the java sources, more specific ReportProperties, I saw that the location of the files is created using the out.dir and out.file property (concattenated together). By default, user.dir from the JVM is used for the directory. If I specify the property report.html.out.dir with the value "" within the report element, the coverage files are located at the place I desire: \xxx\. Looking at the Java source code I get the impression that the idea is to remove the out.dir usage in the future. I looked in the manual and I could not find any reference in this contxt to out.dir. I am new to Ant and Emma, so perhaps I missed it. Perhaps the manual needs to be updated? Is it usefull to add this invest to the defect? If there is already a 'defect' to remove the out.dir usage for the report location, the defect stated in the previous reply is a duplicate.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, out.dir property is intentionally left undocumented, the intention being to phase it out.
The reason for wanting to phase it out is to avoid all kinds of special cases when out.dir is specified and out.file is specified but is an absolute pathname, etc. I just wanted a single simple option for specifying the report location.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree, it is nicer to phase out the out.dir property. It is sufficient to be able to specify the output file.
Perhaps the issue is not that serious (only a windows issue?): if the output file name is specified that starts with a drive letter, the concatenation of user.dir and the specified file results in the output file name. Only if a relative output file name is used the user.dir property has an effect.
Rene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I use ant to run emma and everything works fine. My only problem isthat I get the reports at a location relative to user.dir. I tried the property 'coverage.out.file', at several places, but my reports still show up relative to user.dir. Does anyone have a tip? Perhaps a segment of an ant build file?
As documented, 'coverage.out.file' sets the location of the coverage dump file (*.ec), not the report location.
If you are using ANT, the easiest way to set the report locations is to use 'outfile' attributes on <html>, <txt>, <xml> report configurator elements (nested inside <report>.
I could give you a snippet from build.xml that I am using right now at work, but to be honest it is identical to one of the examples in the reference manual (http://emma.sourceforge.net/reference/ch02s04s02.html):
<html outfile="${coverage.dir}/coverage.html"
depth="method"
columns="name,class,method,block,line"
/>
(${coverage.dir} is set to a custom dir in my project)
ANT usage sections in the reference manual for each of EMMA tools has real-life examples (that is, they were tested in real build.xml files and then pasted into the docs). I recommend you check that content out.
Thanks for the reply, I am now a step further.
I wanted to create the reports in a directory from the root of the drive. We develop with a group and some have their source files on the C: drive and some on the D: drive. I wanted to create the reports in /xxx/coverage. I tried the outfile attribute to archieve this (but failed). Then I encountered the coverage.out.file property, but misinterpreted it. Now I verified that if I specify a complete path like c:/xxx/coverage, the reports will be generated there.
Still, it would be nice if I could specify the location /xxx/coverage instead of c:/xxx/coverage. Now half my group of developers must modify the build file and change c: to d:. Do you think I should file a change request for this? If you have other tips, please let me know.
Thanks, Rene Engbers
I believe the issue may be caused by the exact interpretation of a pathname starting with a "/" (specifically, whether such a pathname is absolute or relative). Not only is this different on win32 and UNIX platforms, ANT task attributes that are file descriptors are massaged by ANT before they are passed into tasks and this processing may not always be correct. The latter is not something EMMA can do much about.
I have a couple of suggestions:
(a) Isn't it easier to create build artifacts (including coverage reports) relative to your build's ${basedir} in the first place? When I design ANT builds, I make everything relative to ${basedir}, period. This makes an ANT build completely absolute disk position-independent and is definitely the way to go.
You seem to be doing almost the same thing (build is independent of whether it is on c: or on d:), I am just asking you to consider the next logical step. I am routinely involved in team projects and in fact these days the team members use a mix of win32 and Linux platforms. My builds require zero changes between win32 and Linux and on win32 they are completely insensitive to drive/directory location.
(b) I believe it is common to factor out small amount of build customization into a file like build.properties that each team member tweaks to suite their taste. You could make ${coverage.dir} a setting like that (it would be set to c:/... or d:/... etc). This requires one more configuration step before a build is fully functional, but it's a price you pay if you don't go the (a) route.
I agree, option A is what we want to obtain.
We only have one agreement regarding directories in our project: results are stored in \xxx\. So our basdir starts with a '\'. For all other tools (java compiler, JUnit) this works. Also Emma has no problem in finding the class files (also relative to our basedir) to instrument. The by Emma instrumented class files are also nicely stored relative to our basedir. The only problem is the report location, somehow now the basedir does not work and the user.dir is used instead.
Understood. Thanks for the details. I have added a new bug issue (https://sourceforge.net/tracker/index.php?func=detail&aid=1077741&group_id=108932&atid=651897) for this.
I have analyzed the problem. Looking at the java sources, more specific ReportProperties, I saw that the location of the files is created using the out.dir and out.file property (concattenated together). By default, user.dir from the JVM is used for the directory. If I specify the property report.html.out.dir with the value "" within the report element, the coverage files are located at the place I desire: \xxx\. Looking at the Java source code I get the impression that the idea is to remove the out.dir usage in the future. I looked in the manual and I could not find any reference in this contxt to out.dir. I am new to Ant and Emma, so perhaps I missed it. Perhaps the manual needs to be updated? Is it usefull to add this invest to the defect? If there is already a 'defect' to remove the out.dir usage for the report location, the defect stated in the previous reply is a duplicate.
Yes, out.dir property is intentionally left undocumented, the intention being to phase it out.
The reason for wanting to phase it out is to avoid all kinds of special cases when out.dir is specified and out.file is specified but is an absolute pathname, etc. I just wanted a single simple option for specifying the report location.
I agree, it is nicer to phase out the out.dir property. It is sufficient to be able to specify the output file.
Perhaps the issue is not that serious (only a windows issue?): if the output file name is specified that starts with a drive letter, the concatenation of user.dir and the specified file results in the output file name. Only if a relative output file name is used the user.dir property has an effect.
Rene