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., namereport.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.namereport.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.