Do all you can in you SE

[mcpot]

I search for a software to do all thet you kan do with a SE phone.
I have heard of EMMA and that you can do a lot of fun things with that program, but i haven't found that program

Any one knows about another program och can help me find a working copy of emma?

e-mail: [email protected]

[Tayyabali81]

Emma Java Coverage HOW V CAN USE IT

emma is working with java, n can b used with webpage

i m giving u complete detail...
take a look on the given stuff below
hopefully, i will helpful for u


Regards

Syed Tayyab Ali Shah


Starting point: SLES-9 installed; Birdman-050606-b build installed and running; logged in as root;

Get yourself a copy of Emma. This will come in an emma.jar archive, which in my case happens to be version 2.0.4217.

We are going to modify the class files of Zen, so listen carefully to master Yoda's advice: "live on the edge he who modifies a running binary does, hrmmm. Your services shut down you must, yes" -- to play it safe, I stopped *all* novell-* services existing in /etc/init.d/

rc-qa-client-408 # /etc/init.d/novell-zenserver stop
Shutting down Novell ZENworks done
[...]

Unlike Jcoverage, Emma is fully capable of instrumenting a jar file without forcing you to expand it. The syntax to accomplish this is the following:

java -cp emma.jar emma instr -m overwrite -cp <jarfile>

most likely, you will want to instrument a number of jar files, and as the number of files to instrument grows, down in inversely proportional fashion goes your desire to retype the command line above. Fortunately, a simple one-line script can solve this problem for you:

xargs -n 1 $JAVA_HOME/jre/bin/java -cp emma.jar emma instr -m overwrite -cp < jarlist.txt

where jarlist.txt is a list of paths (fully qualified or relative to your $PWD), one per line, pointing to the jar files you want to instrument. The quickest way to generate such a list is to run

find . -name "*.jar" > jarlist.txt

from an appropriate location. Then edit jarlist.txt to remove the files you do not want to instrument, but at least we don't have to worry about any typos making it into the list.

Now, without further ado, lets give it a run:

rc-qa-client-408 # xargs -n 1 $JAVA_HOME/jre/bin/java -cp emma.jar emma instr -m overwrite -cp < jarlist.txt

EMMA: processing instrumentation path ...
EMMA: package [com/novell/zenworks/loader/modules/filebrowser] contains classes [ArrayOfString] without full debug info
EMMA: instrumentation path processed in 1407 ms
EMMA: [45 class(es) instrumented, 13 resource(s) copied]
EMMA: metadata merged into [/opt/novell/zenworks/java/coverage.em] {in 105 ms}
EMMA: processing instrumentation path ...
[...]

This presupposes that the emma.jar archive is stored in your current directory. Now, if you were to check, you would find that the metadata file coverage.em has been created in your working directory, containing metadata related to your instrumentation task(s).

rc-qa-client-408 # pwd
/opt/novell/zenworks/java
rc-qa-client-408 # ls -al
total 3834
drwxr-xr-x 3 root root 168 Jun 20 16:39 .
drwxr-xr-x 13 root root 456 Jun 20 16:10 ..
-rw-r--r-- 1 root root 3911607 Jun 20 16:39 coverage.em
-rw-r--r-- 1 root root 379 Jun 20 16:31 jarlist.txt
drwxr-xr-x 2 root root 2072 Jun 20 16:39 lib

All done? No. Now that the instrumentation bytecode has been stuck into your jar archives, all of a sudden emma.jar has become absolutely required to run any of your classes. In a complex application like Zenworks, this means changing a whole lot of classpaths, in a number of interesting places (believe me, I tried) -- there are a number of ways to do this, but all involve unnecessary pain. After poking at a few scripts, I decided to stop and think, and recalled that the ext directory is always part of the classpath (in fact, it is *prepended* to it in the classloader's search algorithm), something that makes our lives a lot easier:

rc-qa-client-408 # cp emma.jar /opt/novell/zenworks/lib/java/jre/lib/ext
rc-qa-client-408 #

All done? No. We are going to run instrumented code, some of which runs in a servelet container, and that means that our coverage data can (potentially) wind up in all sort of different places, depending on what different ideas about home the different running tasks have. To fix this up, we set a few properties:

rc-qa-client-408 # cd /opt/novell/zenworks/lib/java/jre/lib/ext
rc-qa-client-408 # vi emma.properties

emma.coverage.out.file=/opt/novell/zenworks/java
emma.session.out.file=/opt/novell/zenworks/java
emma.metadata.out.file=/opt/novell/zenworks/java

In this case, I am using /opt/novell/zenworks/java as my working directory, and the emma.coverage.out.file property will insure that all my runtime data is gathered in a file in that directory, not somewhere else or in separate places for zlman and tomcat classes. The other two properties are not really required, but they can save us trouble later.

Additionally, you might want to set emma.verbosity.level=silent if you are planning to use an automated test suite, as emma's bytecode can be chatty with comments to stdout that might disrupt your string-matching. Finally, I recommend that you do not set emma.coverage.out.merge=false, as you can actually separate your data gathering runs much better than the software can, and doing so just requires you to delete (or rename) the coverage.ec file that will appear in your chosen directory as soon as data starts to be gathered. After restarting our server, we can run the following:

rc-qa-client-408 # ls
. .. coverage.em jarlist.txt lib
rc-qa-client-408 # zlman ping
EMMA: collecting runtime coverage data ...
Username:Administrator
Password:******
ZLMan 6.7.0, Copyright (C) 2004 Novell, Inc.


Service Name | Status
-------------------+----------
coreAPI | Available
Package Management | Available

EMMA: runtime coverage data merged into [/opt/novell/zenworks/java/coverage.ec] {in 93 ms}
rc-qa-client-408:/opt/novell/zenworks/java # ls
. .. coverage.ec coverage.em jarlist.txt lib
rc-qa-client-408 #

Next, you should know that as far as your coverage testing concerns classes running in a servelet container (like tomcat), you must shut down the container to insure that all coverage runtime data has been flushed to disk. This is a very common requirement, Jcoverage does the same (but then again, Jcoverage offers you a timeout property, which Emma does not... yet. However emma does offer a runtime hook to cause a flush from your running code... but that is another story!).

Emma provides several formats of reporting, some fancier than others. you can refer to Emma's reference manual for the details, but as an example, the following will generate both text and HTML reports from our coverage files:

rc-qa-client-408 # java -cp emma.jar emma report -r txt,html -in coverage.em -in coverage.ec
EMMA: processing input files ...
EMMA: 2 file(s) read and merged in 360 ms
EMMA: not all instrumented classes were compiled with source file
EMMA: debug data: no sources will be embedded in the report.
EMMA: line coverage requested in a report of type [txt] but
EMMA: not all instrumented classes were compiled with line number
EMMA: debug data: this column will be removed from the report.
EMMA: showing up to 3 classes without full debug info per package:
EMMA: com.novell.zenworks.loader.modules.filebrowser.Arr ayOfString
EMMA: writing [txt] report to [/opt/novell/zenworks/java/coverage.txt] ...
EMMA: not all instrumented classes were compiled with source file
EMMA: debug data: no sources will be embedded in the report.
EMMA: line coverage requested in a report of type [html] but
EMMA: not all instrumented classes were compiled with line number
EMMA: debug data: this column will be removed from the report.
EMMA: showing up to 3 classes without full debug info per package:
EMMA: com.novell.zenworks.loader.modules.filebrowser.Arr ayOfString
EMMA: writing [html] report to [/opt/novell/zenworks/java/coverage/index.html] ...
rc-qa-client-408 # ls
. .. coverage coverage.ec coverage.em coverage.txt jarlist.txt lib
rc-qa-client-408 #

The text report does not contain even remotely as much detail as the HTML report, which you can actually tie into the source code by using the -sp repeatable option to point Emma's reporting tool to the sources. Before you do that, make sure you are familiar with Emma's concept of block coverage -- Emma does not instrument every line of code, it intruments blocks that do not contain jump instructions. In exception-prone code, this might result in some interesting results ;-)

This is already pretty compact, but as a nod to good programmer's lazyness (Larry Wall's rule), I will include below a script (qa-instrument) to take care of the instrumenting step.

#! /bin/bash

#The qa-instrument script: uses Emma to instrument a list of classfiles as provided by the user.
The list is composed of relative paths valid from $PWD or absolute paths starting at root.
# Federico Lucifredi - 0.1 - 6/20/05

if [ "$1" = "" ]
then
echo
echo "give name of file containing list of jars to be instrumented."
echo
exit
fi

if [ ! -e "$1" ]
then
echo
echo "list file \"$1\" not found."
echo
exit
fi

echo
echo "instrumenting jar files found in list file $1"
echo

xargs -n 1 /opt/novell/zenworks/lib/java/jre/bin/java emma instr -m overwrite -cp < $1

Note that the script is tied into the Zenworks builtin VM in order to avoid duplicating the emma.properties and emma.jar files into the ext directory of whatever VM might be installed on your system. Of course, if you do decide you want to deal with multiple VMs, I suggest you still keep one copy and link both the jar and the properties f

[mcpot]

if yo simplyfi a lot how will it soud then?

i think i got a copy of emma but the only sign i got is to log in. version 2.8.5.12

i'm not a totaly technical imbesill but i'm not 31337 eather..

[mcpot]

no one has any answer? a software to like change what buttons do, or change the signal streangh meter to a number instead of piles?