Table of Contents
The behavior of EMMA tools and runtime is influenced by a number of EMMA properties (see Section 2, “EMMA property summary” for the full list). These properties address several needs:
Given an EMMA property
(from
the tables in Section 2, “EMMA property summary”), it can be specified in several different ways:
emma.property
;emma.property
defined in an external
java.util.Properties
file;property
defined in a java.util.Properties
classloader resource;<property>
or command
line (-D
) property override.emma.
” in order to be in EMMA namespace.
The following shows different ways of overriding the default
coverage session dump file pathname from ANT or command line. Using
emma.properties
or properties
ANT is convenient when you want to load a large block of EMMA
property settings without keeping them in your makefile or
build.xml
:
From ANT:
<emmajava enabled="${emma.enabled}" libclasspathref="emma.lib" dumpsessiondata="yes" properties="my.properties" classname="Main" classpathref="run.classpath" />where file
my.properties
sets
session.out.file
to some mydir/myfile
value.
From command line:
>java emmarun -Dsession.out.file=mydir/myfile ... >java emmarun -properties my.properties ... >java -cp {directory containing emma.properties} emmarun ... >java -Demma.session.out.file=mydir/myfile emmarun ... >java -Demma.properties=my.properties emmarun ...where file
my.properties
sets
session.out.file
to some mydir/myfile
value.
EMMA property lookup order. Because of multiple ways to specify the same EMMA property, it is necessary to document the exact property lookup mechanism in order to disambiguate potential conflicts. The following lists all possible property lookup layers, in the order from the least specific to the most specific (in other words, later definitions override earlier definitions):
report.txt.out.encoding
,
start out with their default values reflecting Java built-in system properties
like file.encoding
. Other properties have their
defaults set in EMMA code.java.util.Properties
file whose
pathname is the value of the JVM system property
emma.properties
(-Demma.properties=filename
).
EMMA properties in such a file are not
prefixed with “emma.
”.-Demma.property
=value
syntax.emma.properties
using the usual
java.util.Properties
format (without the
“emma.
” prefix). The resource is
looked up first in the most specific of the {current, thread
context} pair of classloaders. If neither one is more specific,
the lookup is done in the current classloader. If the
system classloader is more specific than either the current or
the context classloader, then the system classloader is
used.java.util.Properties
file whose
pathname is the value of a properties
ANT
task attribute or a -properties
command line option. EMMA properties in such a file are
not prefixed with “emma.
”.property
ANT task nested element
(<property name='name
' value='value
'/>
)
or a -D
EMMA command line option
(-Dproperty
=value
).
(Without the
“emma.
” prefix: don't confuse
this with JVM system properties.) Note
that in the <report>
task case this mechanism is largely redundant,
because all report generation properties have dedicated ANT task
attributes.Property shortcuts. In the special case of report generation properties
(report.*
) there is one additional complication. Any
property name that follows the
report.
patterns
is actually a report property shortcut in the
sense that is applies to all report types (plain text, HTML, XML). For
some aspects of report generation (e.g., name
report.units
) this is very
appropriate, but for others (e.g., report.out.encoding
) you are likely to want report
type-specific settings. To do so, you can specify a
report.
property. For example, report_type
.name
report.txt.out.encoding
is
more specific than report.out.encoding
as far as
the plain-text report generator is concerned. Note that the
<report>
ANT task makes this more convenient that
the command line case, because it provides convenience override attributes on all
nested <txt>
, <html>
,
etc elements.