[ cobertura-Feature Requests-2030120 ] Support for Eclipse PDE

[SourceForge.net <no...@so...>]

Feature Requests item #2030120, was opened at 2008-07-28 11:01
Message generated for change (Settings changed) made by nchaitas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: nchaitas (nchaitas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for Eclipse PDE 

Initial Comment:
Hi!
We develop an Eclipse based project with OSGi bundles etc and we tried to introduce Cobertura to it with no success. While there were no problems by simple Junit tests, there were class loading problems by tests that need to get run as JUnit plugin tests. I searched around and I found out that other developers had the same problems too (http://dev.eclipse.org/newslists/news.eclipse.tptp/msg02546.html). Therefore they had to go for EMMA, which seems to deal with these problems thanks to its "in place" (overwrite mode) instrumentation in offline mode and its installation as an extension to JRE (http://dev.eclipse.org/newslists/news.eclipse.platform/msg44478.html) . 
Does Cobertura provide any similar solution for it and if not, is there any intention to face this problem?

Thank you in advance,
neo

----------------------------------------------------------------------

>Comment By: nchaitas (nchaitas)
Date: 2009-01-16 18:18

Message:
Hi everybody!
I have also been able to make Cobertura work with the Eclipse PDE, that's
why I am closing this report (which I had opened myself).
The changes I 've made were:
#1: I 've also instrumented the jars in place, although I don't know if
that was essential or not.
#2: I copied the cobertura.jar and its 4 external libs next to each other
(flat) in <my_jdk>\jre\lib\ext
#3: I've entered in the ant-target call "core-test" of the "suite" target
in the test.xml file of our tests plugin following properties:
	<target name="suite">
		...
		<ant target="core-test" antfile="${library-file}"
dir="${eclipse-home}">
			...
			<property name="vmargs" value="-classpath
${instrumented}/*.jar;${jars}/*.jar -Dosgi.parentClassloader=app
-Dnet.sourceforge.cobertura.datafile=${coberturaScripts}\cobertura.ser"/>
			<property name="jvm" value="${javaCmd}"/>
		</ant>
	</target>
			
Setting -Dosgi.parentClassloader=ext has also worked. However app has been
preferred, because the VM sets up the classloaders with the following
hierarchy: app->ext->boot. Since there were occasionally several
class-loading problems the securest option has been preferred.
It is of course very important to make sure that the value of ${javaCmd}
is <my_jdk>\jre\bin\java, that means the jre installation where you have
copied the cobertura libs (s. #2). Personally I had problems with that,
because the property ${jvm} of my Ant installation had been "secretly"
referring to another java installation.
		
What could still not work is the approach of following the example of
Cobertura's tutorial (Ant Task Reference#Running Tests), that means calling
the <junit> ant task, since this one knows nothing about the Eclipse Test
Framework that is necessary for the Eclipse tests automation (actually it
had not been that easy to get the  Eclipse tests automation to work
anyway!).
I tried to set the same properties as above, but (as expected) with no
success:
		<junit fork="yes" dir="${coberturaScripts}" jvm="${jvmHome}"
failureProperty="test.failed">
			<sysproperty key="osgi.parentClassloader" 
				value="app" />
			<sysproperty key="net.sourceforge.cobertura.datafile"
				file="${coberturaScripts}/cobertura.ser" />
			...
		</junit>
	</target>

On the other hand, the approach that worked (the one with the 3 changes I
've mentioned above) calls at the very end the <java> ant task in the
org.eclipse.test_3.2.0\library.xml of the Eclipse Test Framework like
this:
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
	    		<fileset dir="${eclipse-home}/plugins">
	            	<include name="org.eclipse.equinox.launcher_*.jar"/>
	          	</fileset>
	        </classpath>
				...
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		</java>


----------------------------------------------------------------------

Comment By: Andreas Pakulat (andipak)
Date: 2008-08-04 17:14

Message:
Logged In: YES 
user_id=1486075
Originator: NO

I was now able to make cobertura work, though I'm not sure what of the
various things I tried made it finally run.

My setup now puts cobertura-main.jar from a self-built cobertura into
<jre>/lib/ext and I've changed test.xml from the eclipse-unit testing to
sets the vmargs property before calling the test-plugin's test.xml file
<property name="vmargs"
value="-Dnet.sourceforge.cobertura.datafile=${cobertura.datafile}
-Dosgi.parentClassloader=ext" />

I think thats all modifications I did.

----------------------------------------------------------------------

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:50

Message:
Logged In: YES 
user_id=1486075
Originator: NO

As opposed to the posted snippet I'm directly replacing the plugin .jar's
by the instrumented ones. And I can reproduce the problem why just
executing the java command on the commandline. So it seems eclipse is
somehow not loading the cobertura and related jar's. 

----------------------------------------------------------------------

Comment By: Andreas Pakulat (andipak)
Date: 2008-07-30 17:42

Message:
Logged In: YES 
user_id=1486075
Originator: NO

Missed that sourceforge wouldn't ask me for login before sending the
comment. So that last one was from me.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2008-07-30 17:41

Message:
Logged In: NO 

I'm having the same problem, even adding cobertura.jar along with the asm,
jakarta and log4j jars to the ext/ dir and using that bootloader doesn't
seem to help here.

----------------------------------------------------------------------

Comment By: nchaitas (nchaitas)
Date: 2008-07-30 17:29

Message:
Logged In: YES 
user_id=2160620
Originator: YES

Hi!
One more piece of information that might be useful.
Cobertura gets executed through use of the <junit> Ant task (according to
its instructions), while Eclipse automated tests get executed through the
<java> Ant task (also with fork="true" and , which accept the Ant elements
<jvmarg>, <sysproperty> and <classpath>, which I used to specify the type
of the class loader, the location of the cobertura.ser and of my
instrumented classes respectively. In particular the invocation of this
<java> task looked like this (in my very first attempt):
		<java fork="true" dir="." timeout="${timeout}" jvm="${jvm}"
logError="true"
			classname="org.eclipse.core.launcher.Main"
output="${junit-report-output}/${classname}.txt">
	        <classpath>
    		  	<fileset dir="${eclipse-home}/plugins">
            	<include name="org.eclipse.equinox.launcher_*.jar"/>
          	</fileset>
	        </classpath>
		    <arg line="-application ${application}"/>
		    <arg line="-data ${data-dir}"/>
		    <arg line="formatter=${formatter},${test-output}"/>
		    <arg line="-testPluginName ${plugin-name}"/>
		    <arg line="-className ${classname}"/>
		    <arg line="-os ${os}"/>
		    <arg line="-ws ${ws}"/>
		    <arg line="-arch ${arch}"/>
		    <arg line="-consolelog"/>
		    <jvmarg line="${vmargs} ${extraVMargs}"/>
		    <sysproperty key="PLUGIN_PATH" value="${plugin-path}"/> 
			 	<!-- Define cobertura specific elements -->
				<sysproperty key="net.sourceforge.cobertura.datafile"
file="${coberturaScripts}/cobertura.ser" />
		    <classpath>
		      <fileset dir="${instrumented}">
		        <include name="**/*.jar"/>
		      </fileset>
		      <fileset dir="${jars}">
		        <include name="**/*.jar"/>
		      </fileset>
	    	</classpath>
				<classpath refid="cobertura.classpath" />
		</java>

As long as I don't instrument my classes and I don't define any cobertura
specific elements in this <java> task my tests run normally.
When I instrument my classes and I use the <junit> task as described in
the cobertura instructions then (after getting an output of many exceptions
on the console upon initialization) only some of my tests get executed, I
assume these are the ones that can get executed as junit tests as well as
junit (Eclipse) plugin tests.

I hope that something of all these could be useful... :o)
Regards,
neo

PS: By the way -even if this does not actually belong to this discussion-,
I had problems with the <cobertura-report> task, particularly with defining
the set of the source files of my multiple eclipse plugin-projects. This
problem is documented very good here
(https://sourceforge.net/mailarchive/forum.php?thread_name=780385.62813.qm%40web56601.mail.re3.yahoo.com&forum_name=cobertura-devel)
by another user and the solution proposed there (namely the use of groovy
ant task) did work for me, indeed! However, I believe that allowing the Ant
element <dirset> to <cobertura-report> task would be the clean solution for
defining multiple source packages. In my opinion a feature request upon
that too is not such a bad idea, since the use of the <cobertura-merge>
task to merge multiple coverage data files is not so convenient.


----------------------------------------------------------------------

Comment By: nchaitas (nchaitas)
Date: 2008-07-29 13:55

Message:
Logged In: YES 
user_id=2160620
Originator: YES

Hi John,

thanks for your response.
Unfortunately I am not familiar with the way the code coverage tools
instrument the classes, but it seems that you do, so I appreciate a
lot your assistance!

The EMMA link you mentioned is:
http://emma.sourceforge.net/userguide/ar01s02s03.html (for command line)
and
http://emma.sourceforge.net/userguide/ar01s03s03.html (for ANT)

The in-place instrumentation is not the reason it doesn't work, since
I manually replace the original classes with the instrumented ones.

In Eclipse there are 4 ways to define the classloader type (s.
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg04389.html).
EMMA works for eclipse, when it gets installed on the ext/ directory
of the JRE and the Eclipse classloader type is set to "ext" (however
EMMA's got just one jar, while cobertura.jar depends on 4 other jars).
I tried putting cobertura.jar on the JRE/ext directory and setting the
Eclipse classloader type to "ext" and it didn't work.
My classes could still not find
cobertura.jar\net\sourceforge\cobertura\coveragedata\HasBeenInstrumented.class.

I also tried for instance to create an Eclipse cobertura plugin (a wrapper

of cobertura.jar and its 4 required jars under lib/), add it as a
dependency 
to my plugins and then integrate it to my build process (without any
references 
to it of course). While in the Eclipse IDE my plugins set to depend on my
new 
cobertura plugin could reference class coveragedata\HasBeenInstrumented
the 
generated byte code instrumented into my plugins in the scope of the
testing 
process still did not work.

I read somewhere that EMMA and cobertura generate pretty different
instrumented byte codes, so I just guessed, that the way the generated 
byte code references the cobertura classes was the problem.
For this reason and because it seems I was not the only one who tried
to integrate cobertura to Eclipse PDE (Plugin Development Environment)
I posted this issue under feature requests and not as a bug.

I hope that that could clear up things a little bit.
Kind regards,
neo

----------------------------------------------------------------------

Comment By: John Lewis (lewijw)
Date: 2008-07-28 14:22

Message:
Logged In: YES 
user_id=1031161
Originator: NO

Can you give me the link for EMMA's instructions for offline mode
operation?

It is possible to have Cobertura instrument in place.   Just don't use the
todir attribute of <cobertura-instrument>.

I'm not a plugin developer, but I imagine you need to make sure Cobertura
is loaded by the root classloader.  I'm not sure how to do that with
Eclipse.

I would like to get this working.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=720018&aid=2030120&group_id=130558