I am trying to understand why the emmajava task needs a reference to emma.lib as the libclasspathref attribute. The classloader for emma should be able to pick up the classes without this attribute. In fact, when you hit emmajava task, it starts running with those two jars in the classpath already. What is the use of this extra attribute???
It would make emma even easier with one less needed attribute.
thanks,
dean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Using this attribute solves at least two problems:
(a) The attribute value is used under the hood to form classpath A when the JVM used for emmarun is forked:
java -cp A emmarun -cp B <your main class> ...
(Here B is your application classpath and it is somewhat important to keep A and B separate.)
It is important to realize that emma.jar is needed not only for the task classes themselves, but for your instrumented classes when they execute at runtime.
AFAIK, there is no clean way to pass the classpath used for loading an ANT task definition to the actual task invocations. Hence my ANT examples (build-onthefly.xml) solve this problem by defining "emma.lib" classpathref and reusing it for <taskdef> and <emmajava>.
(b) Placing emma.jar into <jre>/lib/ext is the recommended way to use EMMA. It is safe and eliminates the need for having an explicit classpath entry for EMMA.
Unfortunately, ANT classloading is less than perfect. Specifically, their classloader does not make extension classes visible to ANT tasks unless the classes come from hardcoded lists of extension jars they keep specific to every Java version. It has been a silly decision on their part: not only it makes ANT in-proc execution not equivalent to forked execution, it also locks ANT's dev team forever into having to update such lists for every new Java version or JDK build.
I work around classloading issues brought about by this design by asking the user to give me an explicit classpath location for EMMA and forking my tasks if necessary. As the ANT dev team makes new and haphazard classloading design decisions (as they have done in ANT 1.6), I am somewhat insulated from such vagaries.
If you think there is a better approach here, I am all ears.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now look at the URL, notice that it contains the exact location of the jar file that the EmmaAntTask is in. By parsing this, you can easily get the file reference to the jar file. Once you have the reference to the jar file, you have two choices
1. make sure emma is one and only one jar
2. assume the other jar is in the same directory as the ant jar(ie. require them always to be together)
Then you can fork java or whatever you want supplying the emma jars without the user ever having to specify the location of the emma libraries again.
Does that work for you? It is kind of an interesting idea making emma even easier.
ps. thanks for the great explanation on the other topic with copying many many files. I get that!!!! :)
thanks,
dean
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am familiar with this trick (note that you don't need to make assumptions about the jars being one or being in the same dir, you can just apply the trick twice to two appropriate classes). I wrote a short article about it a while ago: http://www.javaworld.com/javaworld/javaqa/2003-07/01-qa-0711-classsrc.html
Just like it says at the end, I consider this to be kosher for debugging/testing but not for a "product", mostly because it's a hack that is not guaranteed to work.
Another, and more important, reason is that this may not work inside ANT. The trick works only for reasonably well-behaved parent classloaders and I vaguely remember that the one in ANT wasn't it.
So far this has not been a hotly requested feature enhancement. Once I get through the energy barrier of having to re-work the web site I will start proper feature dev again and it's things like red/green bars in the HTML report etc that people seem to crave, etc.
But you are welcome to add a new RFE to the Tracker and link to this discussion thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to understand why the emmajava task needs a reference to emma.lib as the libclasspathref attribute. The classloader for emma should be able to pick up the classes without this attribute. In fact, when you hit emmajava task, it starts running with those two jars in the classpath already. What is the use of this extra attribute???
It would make emma even easier with one less needed attribute.
thanks,
dean
Using this attribute solves at least two problems:
(a) The attribute value is used under the hood to form classpath A when the JVM used for emmarun is forked:
java -cp A emmarun -cp B <your main class> ...
(Here B is your application classpath and it is somewhat important to keep A and B separate.)
It is important to realize that emma.jar is needed not only for the task classes themselves, but for your instrumented classes when they execute at runtime.
AFAIK, there is no clean way to pass the classpath used for loading an ANT task definition to the actual task invocations. Hence my ANT examples (build-onthefly.xml) solve this problem by defining "emma.lib" classpathref and reusing it for <taskdef> and <emmajava>.
(b) Placing emma.jar into <jre>/lib/ext is the recommended way to use EMMA. It is safe and eliminates the need for having an explicit classpath entry for EMMA.
Unfortunately, ANT classloading is less than perfect. Specifically, their classloader does not make extension classes visible to ANT tasks unless the classes come from hardcoded lists of extension jars they keep specific to every Java version. It has been a silly decision on their part: not only it makes ANT in-proc execution not equivalent to forked execution, it also locks ANT's dev team forever into having to update such lists for every new Java version or JDK build.
I work around classloading issues brought about by this design by asking the user to give me an explicit classpath location for EMMA and forking my tasks if necessary. As the ANT dev team makes new and haphazard classloading design decisions (as they have done in ANT 1.6), I am somewhat insulated from such vagaries.
If you think there is a better approach here, I am all ears.
I do have something that might work. Something like this
URL url = EmmaAntTask.class.getResource("EmmaAntTask.class")
Now look at the URL, notice that it contains the exact location of the jar file that the EmmaAntTask is in. By parsing this, you can easily get the file reference to the jar file. Once you have the reference to the jar file, you have two choices
1. make sure emma is one and only one jar
2. assume the other jar is in the same directory as the ant jar(ie. require them always to be together)
Then you can fork java or whatever you want supplying the emma jars without the user ever having to specify the location of the emma libraries again.
Does that work for you? It is kind of an interesting idea making emma even easier.
ps. thanks for the great explanation on the other topic with copying many many files. I get that!!!! :)
thanks,
dean
I am familiar with this trick (note that you don't need to make assumptions about the jars being one or being in the same dir, you can just apply the trick twice to two appropriate classes). I wrote a short article about it a while ago: http://www.javaworld.com/javaworld/javaqa/2003-07/01-qa-0711-classsrc.html
Just like it says at the end, I consider this to be kosher for debugging/testing but not for a "product", mostly because it's a hack that is not guaranteed to work.
Another, and more important, reason is that this may not work inside ANT. The trick works only for reasonably well-behaved parent classloaders and I vaguely remember that the one in ANT wasn't it.
So far this has not been a hotly requested feature enhancement. Once I get through the energy barrier of having to re-work the web site I will start proper feature dev again and it's things like red/green bars in the HTML report etc that people seem to crave, etc.
But you are welcome to add a new RFE to the Tracker and link to this discussion thread.