Menu
▾
▴
cobertura-devel — General questions about using and developing Cobertura.
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(66) |
Apr
(29) |
May
(85) |
Jun
(66) |
Jul
(24) |
Aug
(139) |
Sep
(72) |
Oct
(26) |
Nov
(142) |
Dec
(34) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(55) |
Feb
(72) |
Mar
(43) |
Apr
(60) |
May
(95) |
Jun
(22) |
Jul
(48) |
Aug
(17) |
Sep
(54) |
Oct
(30) |
Nov
(82) |
Dec
(17) |
| 2007 |
Jan
(23) |
Feb
(38) |
Mar
(46) |
Apr
(12) |
May
(77) |
Jun
(77) |
Jul
(94) |
Aug
(51) |
Sep
(38) |
Oct
(57) |
Nov
(39) |
Dec
(67) |
| 2008 |
Jan
(38) |
Feb
(56) |
Mar
(42) |
Apr
(46) |
May
(37) |
Jun
(43) |
Jul
(52) |
Aug
(22) |
Sep
(22) |
Oct
(34) |
Nov
(37) |
Dec
(29) |
| 2009 |
Jan
(27) |
Feb
(35) |
Mar
(67) |
Apr
(37) |
May
(31) |
Jun
(79) |
Jul
(71) |
Aug
(59) |
Sep
(31) |
Oct
(47) |
Nov
(36) |
Dec
(7) |
| 2010 |
Jan
(15) |
Feb
(87) |
Mar
(38) |
Apr
(33) |
May
(24) |
Jun
(47) |
Jul
(26) |
Aug
(28) |
Sep
(33) |
Oct
(13) |
Nov
(8) |
Dec
(36) |
| 2011 |
Jan
(32) |
Feb
(10) |
Mar
(29) |
Apr
(29) |
May
(17) |
Jun
(14) |
Jul
(33) |
Aug
(11) |
Sep
(7) |
Oct
(7) |
Nov
(6) |
Dec
(10) |
| 2012 |
Jan
(19) |
Feb
(12) |
Mar
(16) |
Apr
(6) |
May
(18) |
Jun
(18) |
Jul
(31) |
Aug
(25) |
Sep
|
Oct
(31) |
Nov
(21) |
Dec
(9) |
| 2013 |
Jan
(8) |
Feb
(16) |
Mar
(8) |
Apr
(7) |
May
(3) |
Jun
(29) |
Jul
(29) |
Aug
|
Sep
(7) |
Oct
(9) |
Nov
(1) |
Dec
(1) |
| 2014 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(13) |
May
(8) |
Jun
(5) |
Jul
(2) |
Aug
(4) |
Sep
(4) |
Oct
(2) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Elliotte H. <el...@me...> - 2005-08-25 15:49:07
|
Matt Kurjanowicz wrote: > Hello, > Sorry for the frequent emails, but I'm new to Cobertura. I've gotten > cobertura to work to generate coverage reports, but those reports > contain the actual test classes, not just the classes that are being > tested. I was wondering if there is any way to exclude those classes > from the report? Probably. I'm not sure. But I do suspect that you'd be better off leaving them in. Occasionally code coverage measurement of the test classes has shown me that code I thought was running and passing wasn't run at all. This can happen due to incorrect naming conventions, bad branches within methods, failure to override a method that you should, or failure to invoke a superclass method from the overriding method. It doesn't happen too often, but when it does it's a real shock; and code coverage tools find this sort of problem very quickly and make it obvious in a way nothing else does. -- Elliotte Rusty Harold el...@me... XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
|
From: Matt K. <mat...@gt...> - 2005-08-25 15:41:32
|
Hello,
Sorry for the frequent emails, but I'm new to Cobertura. I've gotten
cobertura to work to generate coverage reports, but those reports
contain the actual test classes, not just the classes that are being
tested. I was wondering if there is any way to exclude those classes
from the report?
<target name="coverage-reports"
depends="compile-all,prepare"
description="Generate unit test coverage reports.">
<echo message="Coverage Datafile = ${coverage.datafile}" />
<cobertura-instrument datafile="${coverage.datafile}"
todir="${instrumented.classes.dir}">
<fileset dir="${classes.dir}">
<exclude name="**/*Test.class" />
<include name="**/*.class" />
</fileset>
</cobertura-instrument>
<!-- Write our own JUnit task so that its settings work with
cobertura. -->
<junit fork="yes">
<sysproperty key="net.sourceforge.cobertura.datafile"
value="${coverage.datafile}" />
<classpath location="${instrumented.classes.dir}" />
<classpath refid="application.classpath" />
<formatter type="brief" usefile="false" />
<batchtest>
<fileset dir="${instrumented.classes.dir}">
<include name="**/*Test.class" />
</fileset>
</batchtest>
</junit>
<cobertura-report srcdir="${src.dir}"
destdir="${coverage.report.dir}"
datafile="${coverage.datafile}" />
</target>
TIA,
Matt Kurjanowicz
|
|
From: Matt K. <mat...@gt...> - 2005-08-25 12:34:46
|
Hi,
I'm trying to use the cobertura merge task and I'm having a little
trouble. The project that I am working on has multiple subprojects, and
I instrument and run the unit test for each subproject. The
coverage.ser files are put in $BR/$PROJ_NAME, so $BR/proj1/coverage.ser,
$BR/proj2/coverage.ser, etc.... After I generate these files I try to
merge them using:
<cobertura-merge toDir="${build.dir}">
<fileset dir="${project.build.root}/proj1">
<include name="**/coverage.ser" />
</fileset>
<fileset dir="${project.build.root}/proj2">
<include name="**/coverage.ser" />
</fileset>
<fileset dir="${project.build.root}/proj3">
<include name="**/coverage.ser" />
</fileset>
<fileset dir="${project.build.root}/proj4">
<include name="**/coverage.ser" />
</fileset>
</cobertura-merge>
but there is no ${project.build.root}/coverage.ser, so my
cobertura-report task fails.
I'm using ant-1.6.2, java 1.5.0_04, and cobertura-1.6.
What am I missing?
TIA for any help,
-Matt Kurjanowicz
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-25 11:05:53
|
By default JBoss at the end of its shutdown uses=20
Runtime.getRuntime().halt(0);=20
so that JVM is forced to halt. If other shutdown hooks are working
there are terminated - so Cobertura can be terminated in the middle of
serializing datafile (halt method documentation:
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Runtime.html#halt(int))
In case of Tomcat it seems that they do not use such brutal methods,
and Cactus uses standard Tomcat shutdown. But Tomcat shutdown is fired
from separate thread, maybe cobertura-report is run when Tomcat has
not finished its shutdown yet? Could you add sleep task before
launching cobertura-report? Maybe it will help.
Below are presented some technical details and possible solution for
JBoss users.
Grzegorz
---------------------------------------------------------------------------=
-----------------------------
JBoss ServerImpl.java - source:
http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-system/src/main/org/jboss=
/system/server/ServerImpl.java?view=3Dmarkup
Interesting sections:
-------------- ServerImpl.java
public ShutdownHook(final ObjectName controller, final
ObjectName mainDeployer)
{
=09 ...
=20
String value =3D System.getProperty("jboss.shutdown.forceHalt", nu=
ll);
if (value !=3D null) {
forceHalt =3D new Boolean(value).booleanValue();
}
--------------
public void run()
{
shutdown();
// later bitch
if (forceHalt) {
System.out.println("Halting VM");
Runtime.getRuntime().halt(0);
}
}
--------------
BTW. Nice comment ;)
---------------------------------------------------------------------------=
-----------------------------
JBoss changelog:
http://sourceforge.net/project/shownotes.php?release_id=3D97289
Section: Changes between JBoss_3_0_1RC1 and JBoss_3_0_0
Added jboss.shutdown.forceHalt system property, which defaults to true.
This value controls whether or not the shutdown hook will force the vm
to exit after shutdown has been completed. This might help for situat=
ions
where the vm is crazy, locked up in socket io or something... or not.
------------
You can use this option to prevent Runtime.halt use:
run -Djboss.shutdown.forceHalt=3Dfalse
You should see these lines at JBoss shutdown (this lines are written
on standard output, so won't see them in logs):
Shutdown complete
When this option is not used additionaly this line is presented:
Shutdown complete
Halting VM
NOTICE: I will be able to test it with Cobertura installation on Linux tomo=
rrow.
On 8/24/05, yamaduc <ya...@gm...> wrote:
> Here's the stack, see below.
>=20
> Thanks for your help.
>=20
> Maybe I can get a thread dump, if that'll help.
>=20
>=20
> [cobertura-report] java.io.EOFException
> [cobertura-report] at
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.jav=
a:2165)
> [cobertura-report] at
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStrea=
m.java:2631)
> [cobertura-report] at
> java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:734)
> [cobertura-report] at
> java.io.ObjectInputStream.<init>(ObjectInputStream.java:253)
> [cobertura-report] at
> net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCovera=
geData(CoverageDataFileHandler.java:97)
> [cobertura-report] at
> net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler.loadCovera=
geData(CoverageDataFileHandler.java:68)
> [cobertura-report] at
> net.sourceforge.cobertura.reporting.Main.parseArguments(Main.java:91)
> [cobertura-report] at
> net.sourceforge.cobertura.reporting.Main.main(Main.java:161)
>=20
>=20
>=20
> On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > Yeah, it looks pretty strange. I have noticed it recently when running
> > instrumented application in JBoss. On Windows it worked ok, but under
> > Linux I got EOFException when reporting task was reading cobertura.ser
> > - it seems that cobertura.ser was truncated (or maybe not fully
> > written) during instrumentation. I have no time to investigate it yet,
> > but now I see it was no accident, and I will look at it.
> >
> > cobertura.ser is written during virtual machine shutdown, maybe some
> > applications that also perfom some actions on VM shutdown use
> > java.lang.Runtime.halt method at the end? I am not sure.
> >
> > Grzegorz
> >
> > PS. Eh, I won't be able to do anything today.
> >
> > On 8/24/05, yamaduc <ya...@gm...> wrote:
> > > well, this is strange.
> > >
> > > I put all the cobertura jar in the war file.
> > >
> > > The classes get instrumented, but during the report, it deletes
> > > everything in the cobertura.ser
> > >
> > > Then an EOF exception is thrown.
> > >
> > > On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > Hmmmm... I am not sure what is the cause. Have you add cobertura.ja=
r
> > > > and all depended libraries to the war (or to Tomcat's lib directory=
)?
> > > > And have you put all classes and other resources that were not
> > > > instrumented (e.g. interfaces, files with properties) to these
> > > > instrumented?
> > > >
> > > > Grzegorz
> > > >
> > > > On 8/24/05, yamaduc <ya...@gm...> wrote:
> > > > > Cobertura isn't throwing any exception.
> > > > > If I put the instrumented classes in the war file I get the follo=
wing error.
> > > > >
> > > > > [cactus] --------------------------------------------------------=
---------
> > > > > [cactus] Running tests against Tomcat 4.1.27 @ http://localhost:8=
810
> > > > > [cactus] --------------------------------------------------------=
---------
> > > > > [cactus] Testsuite: com.goldengate.veridata.struts.actions.TestCr=
eateGroupAction
> > > > > [cactus] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.63=
sec
> > > > >
> > > > > [cactus] ------------- Standard Error -----------------
> > > > > [cactus] log4j:WARN No appenders could be found for logger
> > > > > (org.apache.cactus.internal.configuration.ConfigurationInitialize=
r).
> > > > > [cactus] log4j:WARN Please initialize the log4j system properly.
> > > > > [cactus] ------------- ---------------- ---------------
> > > > > [cactus] Testcase:
> > > > > testExceptionBean(org.apache.cactus.ServletTestCase): Caused =
an
> > > > > ERROR
> > > > > [cactus] Error while initializing ActionServlet: Parsing error
> > > > > processing resource path /WEB-INF/struts-config.xml
> > > > > [cactus] junit.framework.AssertionFailedError: Error while
> > > > > initializing ActionServlet: Parsing error processing resource pat=
h
> > > > > /WEB-INF/struts-config.
> > > > > [cactus] at
> > > > > servletunit.struts.CactusStrutsTestCase.getActionServlet(CactusSt=
rutsTestCase.java:486)
> > > > > [cactus] at
> > > > > servletunit.struts.CactusStrutsTestCase.actionPerform(CactusStrut=
sTestCase.java:536)
> > > > > [cactus] at
> > > > > com.goldengate.veridata.struts.actions.TestCreateGroupAction.test=
ExceptionBean(TestCreateGroupAction.java:63)
> > > > > [cactus] at
> > > > > org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(A=
bstractCactusTestCase.java:153)
> > > > > [cactus] at
> > > > > org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(Ab=
stractWebTestCaller.java:119)
> > > > > [cactus] at
> > > > > org.apache.cactus.internal.server.AbstractWebTestController.handl=
eRequest_aroundBody0(AbstractWebTestController.java:93)
> > > > > [cactus] at
> > > > > org.apache.cactus.internal.server.AbstractWebTestController.handl=
eRequest_aroundBody1$advice(AbstractWebTestController.java:217)
> > > > > [cactus] at
> > > > > org.apache.cactus.internal.server.AbstractWebTestController.handl=
eRequest(AbstractWebTestController.java)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2=
(ServletTestRedirector.java:101)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3=
$advice(ServletTestRedirector.java:217)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doPost(ServletTest=
Redirector.java)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(=
ServletTestRedirector.java:72)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$=
advice(ServletTestRedirector.java:217)
> > > > > [cactus] at
> > > > > org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestR=
edirector.java)
> > > > > [cactus] at javax.servlet.http.HttpServlet.service(HttpServle=
t.java:740)
> > > > > [cactus] at javax.servlet.http.HttpServlet.service(HttpServle=
t.java:853)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(=
ApplicationFilterChain.java:247)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ApplicationFilterChain.doFilter(Applicat=
ionFilterChain.java:193)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrap=
perValve.java:256)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:643)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline=
.java:480)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:=
995)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardContextValve.invoke(StandardCont=
extValve.java:191)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:643)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline=
.java:480)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:=
995)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardContext.invoke(StandardContext.j=
ava:2416)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostVal=
ve.java:180)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:643)
> > > > > [cactus] at
> > > > > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispa=
tcherValve.java:171)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:641)
> > > > > [cactus] at
> > > > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportVal=
ve.java:172)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:641)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline=
.java:480)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:=
995)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngin=
eValve.java:174)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveCo=
ntext.invokeNext(StandardPipeline.java:643)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline=
.java:480)
> > > > > [cactus] at
> > > > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:=
995)
> > > > > [cactus] at
> > > > > org.apache.catalina.connector.http.HttpProcessor.process(HttpProc=
essor.java:1040)
> > > > > [cactus] at
> > > > > org.apache.catalina.connector.http.HttpProcessor.run(HttpProcesso=
r.java:1151)
> > > > > [cactus] at java.lang.Thread.run(Thread.java:534)
> > > > >
> > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > Try to run ant with -v option, there should be stack trace with=
more detail.
> > > > > > Did you put only instrumented classes into war? If Cobertura do=
es not
> > > > > > instrument class for some reason (e.g. for interface) it does n=
ot put
> > > > > > uninstrumented file among instrumented. Maybe some interface is
> > > > > > missing? (You should copy all remaining files to the war).
> > > > > >
> > > > > > Or maybe Cobertura library is not in Tomcat libs?
> > > > > >
> > > > > > I am just guessing.
> > > > > >
> > > > > > Grzegorz
> > > > > >
> > > > > > PS. I am going sleep, so I won't be able to answer today.
> > > > > >
> > > > > > On 8/24/05, yamaduc <ya...@gm...> wrote:
> > > > > > > Here's what happens when i put the instrumented classes in th=
e war file.
> > > > > > >
> > > > > > > [cactus] Testcase:
> > > > > > > testExceptionBean(org.apache.cactus.ServletTestCase): Cau=
sed an
> > > > > > > ERROR
> > > > > > > [cactus] Error while initializing ActionServlet: Parsing erro=
r
> > > > > > > processing resource path /WEB-INF/struts-config.xml
> > > > > > > [cactus] junit.framework.AssertionFailedError: Error while
> > > > > > > initializing ActionServlet: Parsing error processing resource=
path
> > > > > > > /WEB-INF/struts-config.xml
> > > > > > >
> > > > > > > I tried it without the instrumented classes in the war file a=
nd this
> > > > > > > message does not appear.
> > > > > > >
> > > > > > >
> > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > If you put insturmented classes in serverclasses dir for We=
blogic,
> > > > > > > > then they were treaten as part of web application.
> > > > > > > >
> > > > > > > > You can try (at least for test) to instrument war - it shou=
ld be
> > > > > > > > possible from Cobertura 1.5. Be aware that you will need co=
bertura.jar
> > > > > > > > (and dependend) in some tomcat lib subdirectory (or you can=
pack it
> > > > > > > > into war).
> > > > > > > >
> > > > > > > > Grzegorz
> > > > > > > >
> > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > I had this working before with weblogic just fine.
> > > > > > > > >
> > > > > > > > > I'm using tomcat now.
> > > > > > > > >
> > > > > > > > > With weblogic, i didn't need to put the instrumented clas=
ses in the
> > > > > > > > > war/ear file.
> > > > > > > > >
> > > > > > > > > I put the instrumented classes in the server's classpath =
and it worked fine.
> > > > > > > > >
> > > > > > > > > I'll try to put them in the war and see what happens.
> > > > > > > > >
> > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > > > Correct me if I'm wrong, cactus task work this way:
> > > > > > > > > >
> > > > > > > > > > - deploy war inside application container
> > > > > > > > > > - run tests on deployed application by cactus
> > > > > > > > > >
> > > > > > > > > > So if I get it right, classes packed into war are used =
when performing
> > > > > > > > > > tests. When you specifiy classpath inside cactus task, =
it specifies
> > > > > > > > > > classpath for test classes. So you need insturmented cl=
asses packed
> > > > > > > > > > into war, so that they are run during tests.
> > > > > > > > > >
> > > > > > > > > > Grzegorz
> > > > > > > > > >
> > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > so i should have the instrumented classes instead of =
the standard classes?
> > > > > > > > > > >
> > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrot=
e:
> > > > > > > > > > > > One more hit, maybe in created war you do not have =
instrumented classes?
> > > > > > > > > > > >
> > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > > > The date never changes.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> =
wrote:
> > > > > > > > > > > > > > Yes, it should be updated when tests are run bu=
t size will be the
> > > > > > > > > > > > > > same. Check file change date.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Reports does not update cobertura.ser.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Grzegorz
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > > > > > Is the cobertura.ser supposed to update durin=
g the report process?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I watched it after instrumentation, its 691k.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > After my tests run and the reports are execut=
ed, it's still the same 691k.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote=
:
> > > > > > > > > > > > > > > > Well, I tried passing it in as a runtime pa=
ramter to the jvm.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Then the report task complained, couldn't f=
ind cobertura.ser.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > So, I added datafile to the ant task and th=
e error message went away,
> > > > > > > > > > > > > > > > see ant target below.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I only have one .ser file.
> > > > > > > > > > > > > > > > <cobertura-instrument datafile=3D"${test.di=
r}/cobertura.ser"
> > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <target name=3D"coverage" descripti=
on=3D"HTML coverage reports can be
> > > > > > > > > > > > > > > > found in build/coverage">
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <mkdir dir=3D"${test.result=
s}/coverage"/>
> > > > > > > > > > > > > > > > <cobertura-report srcdir=3D=
"${src.dir}"
> > > > > > > > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <echo>
> > > > > > > > > > > > > > > > Cobertura reports h=
ave been generated.
> > > > > > > > > > > > > > > > The HTML report is =
${test.results}/coverage/index.html
> > > > > > > > > > > > > > > > </echo>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <hauserx@gmail=
.com> wrote:
> > > > > > > > > > > > > > > > > Hey,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > You probably do not set property net.sour=
ceforge.cobertura.datafile
> > > > > > > > > > > > > > > > > when running tests (I do not know how to =
do it inside cactus task). Do
> > > > > > > > > > > > > > > > > you get additional cobertura.ser in direc=
tory where tests are run?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Grzegorz
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> w=
rote:
> > > > > > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I have the following build script.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <target name=3D"instrument" depends=3D"=
compile" description=3D"Add Cobertura
> > > > > > > > > > > > > > > > > > instrumentation">
> > > > > > > > > > > > > > > > > > <!-- instrument the app=
lication classes, writing the instrumented
> > > > > > > > > > > > > > > > > > classes into ${instrumented.classes}. -=
->
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <cobertura-instrument d=
atafile=3D"${test.dir}/cobertura.ser"
> > > > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > > > > > > > > > <!-- Note that =
the following line causes instrument to ignore any
> > > > > > > > > > > > > > > > > > source lin=
e containing a reference to log4j, for the purposes
> > > > > > > > > > > > > > > > > > of cov=
erage reporting. -->
> > > > > > > > > > > > > > > > > > <ignore regex=
=3D"org.apache.log4j.*"/>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <fileset dir=3D=
"${classes.dir}">
> > > > > > > > > > > > > > > > > > <!-- in=
strument all the application classes, but don't instrument
> > > > > > > > > > > > > > > > > > the test classes. -->
> > > > > > > > > > > > > > > > > > <includ=
e name=3D"**/*.class"/>
> > > > > > > > > > > > > > > > > > <exclud=
e name=3D"**/*Test.class"/>
> > > > > > > > > > > > > > > > > > </fileset>
> > > > > > > > > > > > > > > > > > </cobertura-instrument>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <target name=3D"test" depends=3D"prepar=
e.test.package" description=3D"Run
> > > > > > > > > > > > > > > > > > the tests on the defined container">
> > > > > > > > > > > > > > > > > > <!-- Run the tests -->
> > > > > > > > > > > > > > > > > > <mkdir dir=3D"${test.re=
sults}/tomcat4x"/>
> > > > > > > > > > > > > > > > > > <cactus warfile=3D"${te=
st-war.dir}/${app.name}-${app.version}.war"
> > > > > > > > > > > > > > > > > > fork=3D"yes" failureproperty=3D"tests.f=
ailed" haltonerror=3D"true">
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <!-- Configure =
the cactus task for logging -->
> > > > > > > > > > > > > > > > > > <cactusproperty=
server=3D"false"
> > > > > > > > > > > > > > > > > > propert=
iesFile=3D"${meta.dir}/${configtype}/test/logging_client.properties"/>
> > > > > > > > > > > > > > > > > > <cactusproperty=
server=3D"true"
> > > > > > > > > > > > > > > > > > propert=
iesFile=3D"${meta.dir}/${configtype}/test/logging_server.properties"/>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <!-- Additional=
jars that will be added to the classpath used to start the
> > > > > > > > > > > > > > > > > > contai=
ner (in addition to the container jars themseleves which are
> > > > > > > > > > > > > > > > > > automa=
tically added by the <cactus> task -->
> > > > > > > > > > > > > > > > > > <containerclass=
path>
> > > > > > > > > > > > > > > > > > <pathel=
ement path=3D"${test-props.dir}"/>
> > > > > > > > > > > > > > > > > > </containerclas=
spath>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <classpath>
> > > > > > > > > > > > > > > > > > <pathel=
ement path=3D"${instrumented.classes}"/>
> > > > > > > > > > > > > > > > > > <pathel=
ement path=3D"${classes.dir}"/>
> > > > > > > > > > > > > > > > > > <pathel=
ement location=3D"${test-lib.dir}/my-tests.jar"/>
> > > > > > > > > > > > > > > > > > <path r=
efid=3D"project.classpath"/>
> > > > > > > > > > > > > > > > > > </classpath>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <containerset>
> > > > > > > > > > > > > > > > > > <tomcat=
4x if=3D"tomcat-dist.dir"
> > > > > > > > > > > > > > > > > > =
dir=3D"${tomcat-dist.dir}" port=3D"${test.port}"
> > > > > > > > > > > > > > > > > > =
output=3D"${test.results}/tomcat4x.out"
> > > > > > > > > > > > > > > > > > =
todir=3D"${test.results}/tomcat4x"
> > > > > > > > > > > > > > > > > > =
tmpdir=3D"${test.temp.dir}"
> > > > > > > > > > > > > > > > > > =
jvmArgs=3D"-DGG_HOME=3DC:/test"/>
> > > > > > > > > > > > > > > > > > </containerset>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <formatter type=
=3D"brief" usefile=3D"false"/>
> > > > > > > > > > > > > > > > > > <formatter type=
=3D"xml"/>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <batchtest>
> > > > > > > > > > > > > > > > > > <filese=
t dir=3D"${testsrc.dir}">
> > > > > > > > > > > > > > > > > > =
<include name=3D"**/Test*.java"/>
> > > > > > > > > > > > > > > > > > =
<exclude name=3D"**/Test*All.java"/>
> > > > > > > > > > > > > > > > > > </files=
et>
> > > > > > > > > > > > > > > > > > </batchtest>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > </cactus>
> > > > > > > > > > > > > > > > > > <!-- Generate the JUnit reports -->
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <junitreport todir=3D"$=
{test.results}/tomcat4x">
> > > > > > > > > > > > > > > > > > <fileset dir=3D=
"${test.results}/tomcat4x"
> > > > > > > > > > > > > > > > > > =
includes=3D"TEST-*.xml"/>
> > > > > > > > > > > > > > > > > > <report todir=
=3D"${test.results}/tomcat4x"
> > > > > > > > > > > > > > > > > > =
format=3D"frames"/>
> > > > > > > > > > > > > > > > > > </junitreport>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <fail if=3D"tests.faile=
d">At least one test failed!</fail>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <target name=3D"coverage" description=
=3D"HTML coverage reports can be
> > > > > > > > > > > > > > > > > > found in build/coverage">
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <mkdir dir=3D"${test.re=
sults}/coverage"/>
> > > > > > > > > > > > > > > > > > <cobertura-report srcdi=
r=3D"${src.dir}"
> > > > > > > > > > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/=
>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > <echo>
> > > > > > > > > > > > > > > > > > Cobertura repor=
ts have been generated.
> > > > > > > > > > > > > > > > > > The HTML report=
is ${test.results}/coverage/index.html
> > > > > > > > > > > > > > > > > > </echo>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > I'm getting 0% coverage for all tests.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Is there a way to see if the classes ha=
ve been instrumented?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > ---------------------------------------=
----------------
> > > > > > > > > > > > > > > > > > SF.Net email is Sponsored by the Better=
Software Conference & EXPO
> > > > > > > > > > > > > > > > > > September 19-22, 2005 * San Francisco, =
CA * Development Lifecycle Practices
> > > > > > > > > > > > > > > > > > Agile & Plan-Driven Development * Manag=
ing Projects & Teams * Testing & QA
> > > > > > > > > > > > > > > > > > Security * Process Improvement & Measur=
ement * http://www.sqe.com/bsce5sf
> > > > > > > > > > > > > > > > > > _______________________________________=
________
> > > > > > > > > > > > > > > > > > Cobertura-devel mailing list
> > > > > > > > > > > > > > > > > > Cob...@li...
> > > > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/lis=
tinfo/cobertura-devel
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Mark D. <ma...@ki...> - 2005-08-25 02:39:54
|
On Wed, 24 Aug 2005 18:54:51 -0700, Chris DeJong wrote > Hi. I have a question about the maven plugin. > > I'm trying to exclude a set of classes within a maven project, > located in subdirectory target/jaxb, from inclusion in the coverage report. > I've tried assigning different values to the > "maven.cobertura.instrumentation.excludes" property in my maven > build.properties file, such as "target/jaxb", with no luck. Even using > "**/*.class" in there doesn't seem to affect the report. > > Any suggestions? I can't help you with the maven plugin--I haven't used it. Hopefully someone else on this list can give you some info. > Also, is there a key to the html report somewhere, or is it assumed > to be self-explanatory? Nope, there is no key. Which parts are unclear? Maybe we can find a way to improve the report itself. -Mark |
|
From: Chris D. <chr...@tv...> - 2005-08-25 01:54:57
|
Hi. I have a question about the maven plugin. =20 I'm trying to exclude a set of classes within a maven project, located in subdirectory target/jaxb, from inclusion in the coverage report. I've tried assigning different values to the "maven.cobertura.instrumentation.excludes" property in my maven build.properties file, such as "target/jaxb", with no luck. Even using "**/*.class" in there doesn't seem to affect the report. =20 Any suggestions? =20 Also, is there a key to the html report somewhere, or is it assumed to be self-explanatory? =20 =20 Thanks, Chris =20 |
|
From: Carlos S. <ca...@ap...> - 2005-08-25 01:27:25
|
It's not automatic, and won't probably be. The plugin can be improved to allow overriding it as it is the clover plugin IIRC. I've upgraded the plugin in CVS to use cobertura 1.6 and I've uploaded the cobertura 1.6 jar to ibiblio, so in a few hours you should be able to build it from CVS. Any help in mantaining and improving the plugin is appreciated. http://maven-plugins.sourceforge.net/maven-cobertura-plugin/. Regards Carlos Sanchez On 8/23/05, Mark Doliner <Mar...@sa...> wrote: > I believe that should be handled by the maven cobertura plugin people. I= guess it's possible that its automatic... but I would guess not. > http://maven-plugins.sourceforge.net/maven-cobertura-plugin/ > -Mark > > > -----Original Message----- > > From: Elliotte Harold [mailto:el...@me...] > > Sent: Tuesday, August 23, 2005 7:27 AM > > To: Mark Doliner > > Cc: cob...@li... > > Subject: Cobertura 1.6 and Maven > > > > This is perhaps more a maven question than a Cobertura one. > > Is the maven > > plugin going to pick up this new version automatically, or is > > an upgrade > > to that required as well? > > > > -- > > Elliotte Rusty Harold el...@me... > > XML in a Nutshell 3rd Edition Just Published! > > http://www.cafeconleche.org/books/xian3/ > > http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ > > ref=3Dnosim > > > |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-24 19:27:49
|
Yeah, it looks pretty strange. I have noticed it recently when running
instrumented application in JBoss. On Windows it worked ok, but under
Linux I got EOFException when reporting task was reading cobertura.ser
- it seems that cobertura.ser was truncated (or maybe not fully
written) during instrumentation. I have no time to investigate it yet,
but now I see it was no accident, and I will look at it.
cobertura.ser is written during virtual machine shutdown, maybe some
applications that also perfom some actions on VM shutdown use
java.lang.Runtime.halt method at the end? I am not sure.
Grzegorz
PS. Eh, I won't be able to do anything today.
On 8/24/05, yamaduc <ya...@gm...> wrote:
> well, this is strange.
>=20
> I put all the cobertura jar in the war file.
>=20
> The classes get instrumented, but during the report, it deletes
> everything in the cobertura.ser
>=20
> Then an EOF exception is thrown.
>=20
> On 8/24/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > Hmmmm... I am not sure what is the cause. Have you add cobertura.jar
> > and all depended libraries to the war (or to Tomcat's lib directory)?
> > And have you put all classes and other resources that were not
> > instrumented (e.g. interfaces, files with properties) to these
> > instrumented?
> >
> > Grzegorz
> >
> > On 8/24/05, yamaduc <ya...@gm...> wrote:
> > > Cobertura isn't throwing any exception.
> > > If I put the instrumented classes in the war file I get the following=
error.
> > >
> > > [cactus] ------------------------------------------------------------=
-----
> > > [cactus] Running tests against Tomcat 4.1.27 @ http://localhost:8810
> > > [cactus] ------------------------------------------------------------=
-----
> > > [cactus] Testsuite: com.goldengate.veridata.struts.actions.TestCreate=
GroupAction
> > > [cactus] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.63 sec
> > >
> > > [cactus] ------------- Standard Error -----------------
> > > [cactus] log4j:WARN No appenders could be found for logger
> > > (org.apache.cactus.internal.configuration.ConfigurationInitializer).
> > > [cactus] log4j:WARN Please initialize the log4j system properly.
> > > [cactus] ------------- ---------------- ---------------
> > > [cactus] Testcase:
> > > testExceptionBean(org.apache.cactus.ServletTestCase): Caused an
> > > ERROR
> > > [cactus] Error while initializing ActionServlet: Parsing error
> > > processing resource path /WEB-INF/struts-config.xml
> > > [cactus] junit.framework.AssertionFailedError: Error while
> > > initializing ActionServlet: Parsing error processing resource path
> > > /WEB-INF/struts-config.
> > > [cactus] at
> > > servletunit.struts.CactusStrutsTestCase.getActionServlet(CactusStruts=
TestCase.java:486)
> > > [cactus] at
> > > servletunit.struts.CactusStrutsTestCase.actionPerform(CactusStrutsTes=
tCase.java:536)
> > > [cactus] at
> > > com.goldengate.veridata.struts.actions.TestCreateGroupAction.testExce=
ptionBean(TestCreateGroupAction.java:63)
> > > [cactus] at
> > > org.apache.cactus.internal.AbstractCactusTestCase.runBareServer(Abstr=
actCactusTestCase.java:153)
> > > [cactus] at
> > > org.apache.cactus.internal.server.AbstractWebTestCaller.doTest(Abstra=
ctWebTestCaller.java:119)
> > > [cactus] at
> > > org.apache.cactus.internal.server.AbstractWebTestController.handleReq=
uest_aroundBody0(AbstractWebTestController.java:93)
> > > [cactus] at
> > > org.apache.cactus.internal.server.AbstractWebTestController.handleReq=
uest_aroundBody1$advice(AbstractWebTestController.java:217)
> > > [cactus] at
> > > org.apache.cactus.internal.server.AbstractWebTestController.handleReq=
uest(AbstractWebTestController.java)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody2(Ser=
vletTestRedirector.java:101)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doPost_aroundBody3$adv=
ice(ServletTestRedirector.java:217)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doPost(ServletTestRedi=
rector.java)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody0(Serv=
letTestRedirector.java:72)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doGet_aroundBody1$advi=
ce(ServletTestRedirector.java:217)
> > > [cactus] at
> > > org.apache.cactus.server.ServletTestRedirector.doGet(ServletTestRedir=
ector.java)
> > > [cactus] at javax.servlet.http.HttpServlet.service(HttpServlet.ja=
va:740)
> > > [cactus] at javax.servlet.http.HttpServlet.service(HttpServlet.ja=
va:853)
> > > [cactus] at
> > > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl=
icationFilterChain.java:247)
> > > [cactus] at
> > > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF=
ilterChain.java:193)
> > > [cactus] at
> > > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV=
alve.java:256)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:643)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav=
a:480)
> > > [cactus] at
> > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > > [cactus] at
> > > org.apache.catalina.core.StandardContextValve.invoke(StandardContextV=
alve.java:191)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:643)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav=
a:480)
> > > [cactus] at
> > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > > [cactus] at
> > > org.apache.catalina.core.StandardContext.invoke(StandardContext.java:=
2416)
> > > [cactus] at
> > > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j=
ava:180)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:643)
> > > [cactus] at
> > > org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche=
rValve.java:171)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:641)
> > > [cactus] at
> > > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j=
ava:172)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:641)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav=
a:480)
> > > [cactus] at
> > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > > [cactus] at
> > > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal=
ve.java:174)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex=
t.invokeNext(StandardPipeline.java:643)
> > > [cactus] at
> > > org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav=
a:480)
> > > [cactus] at
> > > org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
> > > [cactus] at
> > > org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso=
r.java:1040)
> > > [cactus] at
> > > org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja=
va:1151)
> > > [cactus] at java.lang.Thread.run(Thread.java:534)
> > >
> > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > Try to run ant with -v option, there should be stack trace with mor=
e detail.
> > > > Did you put only instrumented classes into war? If Cobertura does n=
ot
> > > > instrument class for some reason (e.g. for interface) it does not p=
ut
> > > > uninstrumented file among instrumented. Maybe some interface is
> > > > missing? (You should copy all remaining files to the war).
> > > >
> > > > Or maybe Cobertura library is not in Tomcat libs?
> > > >
> > > > I am just guessing.
> > > >
> > > > Grzegorz
> > > >
> > > > PS. I am going sleep, so I won't be able to answer today.
> > > >
> > > > On 8/24/05, yamaduc <ya...@gm...> wrote:
> > > > > Here's what happens when i put the instrumented classes in the wa=
r file.
> > > > >
> > > > > [cactus] Testcase:
> > > > > testExceptionBean(org.apache.cactus.ServletTestCase): Caused =
an
> > > > > ERROR
> > > > > [cactus] Error while initializing ActionServlet: Parsing error
> > > > > processing resource path /WEB-INF/struts-config.xml
> > > > > [cactus] junit.framework.AssertionFailedError: Error while
> > > > > initializing ActionServlet: Parsing error processing resource pat=
h
> > > > > /WEB-INF/struts-config.xml
> > > > >
> > > > > I tried it without the instrumented classes in the war file and t=
his
> > > > > message does not appear.
> > > > >
> > > > >
> > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > If you put insturmented classes in serverclasses dir for Weblog=
ic,
> > > > > > then they were treaten as part of web application.
> > > > > >
> > > > > > You can try (at least for test) to instrument war - it should b=
e
> > > > > > possible from Cobertura 1.5. Be aware that you will need cobert=
ura.jar
> > > > > > (and dependend) in some tomcat lib subdirectory (or you can pac=
k it
> > > > > > into war).
> > > > > >
> > > > > > Grzegorz
> > > > > >
> > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > I had this working before with weblogic just fine.
> > > > > > >
> > > > > > > I'm using tomcat now.
> > > > > > >
> > > > > > > With weblogic, i didn't need to put the instrumented classes =
in the
> > > > > > > war/ear file.
> > > > > > >
> > > > > > > I put the instrumented classes in the server's classpath and =
it worked fine.
> > > > > > >
> > > > > > > I'll try to put them in the war and see what happens.
> > > > > > >
> > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > Correct me if I'm wrong, cactus task work this way:
> > > > > > > >
> > > > > > > > - deploy war inside application container
> > > > > > > > - run tests on deployed application by cactus
> > > > > > > >
> > > > > > > > So if I get it right, classes packed into war are used when=
performing
> > > > > > > > tests. When you specifiy classpath inside cactus task, it s=
pecifies
> > > > > > > > classpath for test classes. So you need insturmented classe=
s packed
> > > > > > > > into war, so that they are run during tests.
> > > > > > > >
> > > > > > > > Grzegorz
> > > > > > > >
> > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > so i should have the instrumented classes instead of the =
standard classes?
> > > > > > > > >
> > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > > > One more hit, maybe in created war you do not have inst=
rumented classes?
> > > > > > > > > >
> > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > The date never changes.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrot=
e:
> > > > > > > > > > > > Yes, it should be updated when tests are run but si=
ze will be the
> > > > > > > > > > > > same. Check file change date.
> > > > > > > > > > > >
> > > > > > > > > > > > Reports does not update cobertura.ser.
> > > > > > > > > > > >
> > > > > > > > > > > > Grzegorz
> > > > > > > > > > > >
> > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > > > Is the cobertura.ser supposed to update during th=
e report process?
> > > > > > > > > > > > >
> > > > > > > > > > > > > I watched it after instrumentation, its 691k.
> > > > > > > > > > > > >
> > > > > > > > > > > > > After my tests run and the reports are executed, =
it's still the same 691k.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > > > > Well, I tried passing it in as a runtime paramt=
er to the jvm.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Then the report task complained, couldn't find =
cobertura.ser.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > So, I added datafile to the ant task and the er=
ror message went away,
> > > > > > > > > > > > > > see ant target below.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I only have one .ser file.
> > > > > > > > > > > > > > <cobertura-instrument datafile=3D"${test.dir}/c=
obertura.ser"
> > > > > > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <target name=3D"coverage" description=
=3D"HTML coverage reports can be
> > > > > > > > > > > > > > found in build/coverage">
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <mkdir dir=3D"${test.results}/c=
overage"/>
> > > > > > > > > > > > > > <cobertura-report srcdir=3D"${s=
rc.dir}"
> > > > > > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > <echo>
> > > > > > > > > > > > > > Cobertura reports have =
been generated.
> > > > > > > > > > > > > > The HTML report is ${te=
st.results}/coverage/index.html
> > > > > > > > > > > > > > </echo>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...=
> wrote:
> > > > > > > > > > > > > > > Hey,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > You probably do not set property net.sourcefo=
rge.cobertura.datafile
> > > > > > > > > > > > > > > when running tests (I do not know how to do i=
t inside cactus task). Do
> > > > > > > > > > > > > > > you get additional cobertura.ser in directory=
where tests are run?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Grzegorz
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote=
:
> > > > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I have the following build script.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <target name=3D"instrument" depends=3D"comp=
ile" description=3D"Add Cobertura
> > > > > > > > > > > > > > > > instrumentation">
> > > > > > > > > > > > > > > > <!-- instrument the applica=
tion classes, writing the instrumented
> > > > > > > > > > > > > > > > classes into ${instrumented.classes}. -->
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <cobertura-instrument dataf=
ile=3D"${test.dir}/cobertura.ser"
> > > > > > > > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > > > > > > > <!-- Note that the =
following line causes instrument to ignore any
> > > > > > > > > > > > > > > > source line co=
ntaining a reference to log4j, for the purposes
> > > > > > > > > > > > > > > > of coverag=
e reporting. -->
> > > > > > > > > > > > > > > > <ignore regex=3D"or=
g.apache.log4j.*"/>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <fileset dir=3D"${c=
lasses.dir}">
> > > > > > > > > > > > > > > > <!-- instru=
ment all the application classes, but don't instrument
> > > > > > > > > > > > > > > > the test classes. -->
> > > > > > > > > > > > > > > > <include na=
me=3D"**/*.class"/>
> > > > > > > > > > > > > > > > <exclude na=
me=3D"**/*Test.class"/>
> > > > > > > > > > > > > > > > </fileset>
> > > > > > > > > > > > > > > > </cobertura-instrument>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <target name=3D"test" depends=3D"prepare.te=
st.package" description=3D"Run
> > > > > > > > > > > > > > > > the tests on the defined container">
> > > > > > > > > > > > > > > > <!-- Run the tests -->
> > > > > > > > > > > > > > > > <mkdir dir=3D"${test.result=
s}/tomcat4x"/>
> > > > > > > > > > > > > > > > <cactus warfile=3D"${test-w=
ar.dir}/${app.name}-${app.version}.war"
> > > > > > > > > > > > > > > > fork=3D"yes" failureproperty=3D"tests.faile=
d" haltonerror=3D"true">
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <!-- Configure the =
cactus task for logging -->
> > > > > > > > > > > > > > > > <cactusproperty ser=
ver=3D"false"
> > > > > > > > > > > > > > > > propertiesF=
ile=3D"${meta.dir}/${configtype}/test/logging_client.properties"/>
> > > > > > > > > > > > > > > > <cactusproperty ser=
ver=3D"true"
> > > > > > > > > > > > > > > > propertiesF=
ile=3D"${meta.dir}/${configtype}/test/logging_server.properties"/>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <!-- Additional jar=
s that will be added to the classpath used to start the
> > > > > > > > > > > > > > > > container =
(in addition to the container jars themseleves which are
> > > > > > > > > > > > > > > > automatica=
lly added by the <cactus> task -->
> > > > > > > > > > > > > > > > <containerclasspath=
>
> > > > > > > > > > > > > > > > <pathelemen=
t path=3D"${test-props.dir}"/>
> > > > > > > > > > > > > > > > </containerclasspat=
h>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <classpath>
> > > > > > > > > > > > > > > > <pathelemen=
t path=3D"${instrumented.classes}"/>
> > > > > > > > > > > > > > > > <pathelemen=
t path=3D"${classes.dir}"/>
> > > > > > > > > > > > > > > > <pathelemen=
t location=3D"${test-lib.dir}/my-tests.jar"/>
> > > > > > > > > > > > > > > > <path refid=
=3D"project.classpath"/>
> > > > > > > > > > > > > > > > </classpath>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <containerset>
> > > > > > > > > > > > > > > > <tomcat4x i=
f=3D"tomcat-dist.dir"
> > > > > > > > > > > > > > > > =
dir=3D"${tomcat-dist.dir}" port=3D"${test.port}"
> > > > > > > > > > > > > > > > =
output=3D"${test.results}/tomcat4x.out"
> > > > > > > > > > > > > > > > =
todir=3D"${test.results}/tomcat4x"
> > > > > > > > > > > > > > > > =
tmpdir=3D"${test.temp.dir}"
> > > > > > > > > > > > > > > > =
jvmArgs=3D"-DGG_HOME=3DC:/test"/>
> > > > > > > > > > > > > > > > </containerset>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <formatter type=3D"=
brief" usefile=3D"false"/>
> > > > > > > > > > > > > > > > <formatter type=3D"=
xml"/>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <batchtest>
> > > > > > > > > > > > > > > > <fileset di=
r=3D"${testsrc.dir}">
> > > > > > > > > > > > > > > > <in=
clude name=3D"**/Test*.java"/>
> > > > > > > > > > > > > > > > <ex=
clude name=3D"**/Test*All.java"/>
> > > > > > > > > > > > > > > > </fileset>
> > > > > > > > > > > > > > > > </batchtest>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > </cactus>
> > > > > > > > > > > > > > > > <!-- Generate the JUnit reports -->
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <junitreport todir=3D"${tes=
t.results}/tomcat4x">
> > > > > > > > > > > > > > > > <fileset dir=3D"${t=
est.results}/tomcat4x"
> > > > > > > > > > > > > > > > in=
cludes=3D"TEST-*.xml"/>
> > > > > > > > > > > > > > > > <report todir=3D"${=
test.results}/tomcat4x"
> > > > > > > > > > > > > > > > for=
mat=3D"frames"/>
> > > > > > > > > > > > > > > > </junitreport>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <fail if=3D"tests.failed">A=
t least one test failed!</fail>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <target name=3D"coverage" description=3D"HT=
ML coverage reports can be
> > > > > > > > > > > > > > > > found in build/coverage">
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <mkdir dir=3D"${test.result=
s}/coverage"/>
> > > > > > > > > > > > > > > > <cobertura-report srcdir=3D=
"${src.dir}"
> > > > > > > > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > <echo>
> > > > > > > > > > > > > > > > Cobertura reports h=
ave been generated.
> > > > > > > > > > > > > > > > The HTML report is =
${test.results}/coverage/index.html
> > > > > > > > > > > > > > > > </echo>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > </target>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I'm getting 0% coverage for all tests.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Is there a way to see if the classes have b=
een instrumented?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -------------------------------------------=
------------
> > > > > > > > > > > > > > > > SF.Net email is Sponsored by the Better Sof=
tware Conference & EXPO
> > > > > > > > > > > > > > > > September 19-22, 2005 * San Francisco, CA *=
Development Lifecycle Practices
> > > > > > > > > > > > > > > > Agile & Plan-Driven Development * Managing =
Projects & Teams * Testing & QA
> > > > > > > > > > > > > > > > Security * Process Improvement & Measuremen=
t * http://www.sqe.com/bsce5sf
> > > > > > > > > > > > > > > > ___________________________________________=
____
> > > > > > > > > > > > > > > > Cobertura-devel mailing list
> > > > > > > > > > > > > > > > Cob...@li...
> > > > > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinf=
o/cobertura-devel
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-24 18:43:28
|
No, it has not been implemented yet. Check: https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D125546= 3&group_id=3D130558&atid=3D720017 Grzegorz On 8/24/05, yamaduc <ya...@gm...> wrote: > In JCoverage there was a parameter com.jcoverage.instrumentation.interval > Is there something like this in cobertura? >=20 > I think this might help with my issue. >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > |
|
From: yamaduc <ya...@gm...> - 2005-08-24 18:33:30
|
In JCoverage there was a parameter com.jcoverage.instrumentation.interval Is there something like this in cobertura? I think this might help with my issue. |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 22:38:56
|
Try to run ant with -v option, there should be stack trace with more detail=
.
Did you put only instrumented classes into war? If Cobertura does not
instrument class for some reason (e.g. for interface) it does not put
uninstrumented file among instrumented. Maybe some interface is
missing? (You should copy all remaining files to the war).
Or maybe Cobertura library is not in Tomcat libs?
I am just guessing.
Grzegorz
PS. I am going sleep, so I won't be able to answer today.
On 8/24/05, yamaduc <ya...@gm...> wrote:
> Here's what happens when i put the instrumented classes in the war file.
>=20
> [cactus] Testcase:
> testExceptionBean(org.apache.cactus.ServletTestCase): Caused an
> ERROR
> [cactus] Error while initializing ActionServlet: Parsing error
> processing resource path /WEB-INF/struts-config.xml
> [cactus] junit.framework.AssertionFailedError: Error while
> initializing ActionServlet: Parsing error processing resource path
> /WEB-INF/struts-config.xml
>=20
> I tried it without the instrumented classes in the war file and this
> message does not appear.
>=20
>=20
> On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > If you put insturmented classes in serverclasses dir for Weblogic,
> > then they were treaten as part of web application.
> >
> > You can try (at least for test) to instrument war - it should be
> > possible from Cobertura 1.5. Be aware that you will need cobertura.jar
> > (and dependend) in some tomcat lib subdirectory (or you can pack it
> > into war).
> >
> > Grzegorz
> >
> > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > I had this working before with weblogic just fine.
> > >
> > > I'm using tomcat now.
> > >
> > > With weblogic, i didn't need to put the instrumented classes in the
> > > war/ear file.
> > >
> > > I put the instrumented classes in the server's classpath and it worke=
d fine.
> > >
> > > I'll try to put them in the war and see what happens.
> > >
> > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > Correct me if I'm wrong, cactus task work this way:
> > > >
> > > > - deploy war inside application container
> > > > - run tests on deployed application by cactus
> > > >
> > > > So if I get it right, classes packed into war are used when perform=
ing
> > > > tests. When you specifiy classpath inside cactus task, it specifies
> > > > classpath for test classes. So you need insturmented classes packed
> > > > into war, so that they are run during tests.
> > > >
> > > > Grzegorz
> > > >
> > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > so i should have the instrumented classes instead of the standard=
classes?
> > > > >
> > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > One more hit, maybe in created war you do not have instrumented=
classes?
> > > > > >
> > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > The date never changes.
> > > > > > >
> > > > > > >
> > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > Yes, it should be updated when tests are run but size will =
be the
> > > > > > > > same. Check file change date.
> > > > > > > >
> > > > > > > > Reports does not update cobertura.ser.
> > > > > > > >
> > > > > > > > Grzegorz
> > > > > > > >
> > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > Is the cobertura.ser supposed to update during the report=
process?
> > > > > > > > >
> > > > > > > > > I watched it after instrumentation, its 691k.
> > > > > > > > >
> > > > > > > > > After my tests run and the reports are executed, it's sti=
ll the same 691k.
> > > > > > > > >
> > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > Well, I tried passing it in as a runtime paramter to th=
e jvm.
> > > > > > > > > >
> > > > > > > > > > Then the report task complained, couldn't find cobertur=
a.ser.
> > > > > > > > > >
> > > > > > > > > > So, I added datafile to the ant task and the error mess=
age went away,
> > > > > > > > > > see ant target below.
> > > > > > > > > >
> > > > > > > > > > I only have one .ser file.
> > > > > > > > > > <cobertura-instrument datafile=3D"${test.dir}/cobertura=
.ser"
> > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <target name=3D"coverage" description=3D"HTML c=
overage reports can be
> > > > > > > > > > found in build/coverage">
> > > > > > > > > >
> > > > > > > > > > <mkdir dir=3D"${test.results}/coverage"=
/>
> > > > > > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > >
> > > > > > > > > > <echo>
> > > > > > > > > > Cobertura reports have been gen=
erated.
> > > > > > > > > > The HTML report is ${test.resul=
ts}/coverage/index.html
> > > > > > > > > > </echo>
> > > > > > > > > >
> > > > > > > > > > </target>
> > > > > > > > > >
> > > > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > > > > Hey,
> > > > > > > > > > >
> > > > > > > > > > > You probably do not set property net.sourceforge.cobe=
rtura.datafile
> > > > > > > > > > > when running tests (I do not know how to do it inside=
cactus task). Do
> > > > > > > > > > > you get additional cobertura.ser in directory where t=
ests are run?
> > > > > > > > > > >
> > > > > > > > > > > Grzegorz
> > > > > > > > > > >
> > > > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > > I have the following build script.
> > > > > > > > > > > >
> > > > > > > > > > > > <target name=3D"instrument" depends=3D"compile" des=
cription=3D"Add Cobertura
> > > > > > > > > > > > instrumentation">
> > > > > > > > > > > > <!-- instrument the application cla=
sses, writing the instrumented
> > > > > > > > > > > > classes into ${instrumented.classes}. -->
> > > > > > > > > > > >
> > > > > > > > > > > > <cobertura-instrument datafile=3D"$=
{test.dir}/cobertura.ser"
> > > > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > > > <!-- Note that the followin=
g line causes instrument to ignore any
> > > > > > > > > > > > source line containing=
a reference to log4j, for the purposes
> > > > > > > > > > > > of coverage report=
ing. -->
> > > > > > > > > > > > <ignore regex=3D"org.apache=
.log4j.*"/>
> > > > > > > > > > > >
> > > > > > > > > > > > <fileset dir=3D"${classes.d=
ir}">
> > > > > > > > > > > > <!-- instrument all=
the application classes, but don't instrument
> > > > > > > > > > > > the test classes. -->
> > > > > > > > > > > > <include name=3D"**=
/*.class"/>
> > > > > > > > > > > > <exclude name=3D"**=
/*Test.class"/>
> > > > > > > > > > > > </fileset>
> > > > > > > > > > > > </cobertura-instrument>
> > > > > > > > > > > >
> > > > > > > > > > > > </target>
> > > > > > > > > > > >
> > > > > > > > > > > > <target name=3D"test" depends=3D"prepare.test.packa=
ge" description=3D"Run
> > > > > > > > > > > > the tests on the defined container">
> > > > > > > > > > > > <!-- Run the tests -->
> > > > > > > > > > > > <mkdir dir=3D"${test.results}/tomca=
t4x"/>
> > > > > > > > > > > > <cactus warfile=3D"${test-war.dir}/=
${app.name}-${app.version}.war"
> > > > > > > > > > > > fork=3D"yes" failureproperty=3D"tests.failed" halto=
nerror=3D"true">
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <!-- Configure the cactus t=
ask for logging -->
> > > > > > > > > > > > <cactusproperty server=3D"f=
alse"
> > > > > > > > > > > > propertiesFile=3D"$=
{meta.dir}/${configtype}/test/logging_client.properties"/>
> > > > > > > > > > > > <cactusproperty server=3D"t=
rue"
> > > > > > > > > > > > propertiesFile=3D"$=
{meta.dir}/${configtype}/test/logging_server.properties"/>
> > > > > > > > > > > >
> > > > > > > > > > > > <!-- Additional jars that w=
ill be added to the classpath used to start the
> > > > > > > > > > > > container (in addi=
tion to the container jars themseleves which are
> > > > > > > > > > > > automatically adde=
d by the <cactus> task -->
> > > > > > > > > > > > <containerclasspath>
> > > > > > > > > > > > <pathelement path=
=3D"${test-props.dir}"/>
> > > > > > > > > > > > </containerclasspath>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <classpath>
> > > > > > > > > > > > <pathelement path=
=3D"${instrumented.classes}"/>
> > > > > > > > > > > > <pathelement path=
=3D"${classes.dir}"/>
> > > > > > > > > > > > <pathelement locati=
on=3D"${test-lib.dir}/my-tests.jar"/>
> > > > > > > > > > > > <path refid=3D"proj=
ect.classpath"/>
> > > > > > > > > > > > </classpath>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > <containerset>
> > > > > > > > > > > > <tomcat4x if=3D"tom=
cat-dist.dir"
> > > > > > > > > > > > d=
ir=3D"${tomcat-dist.dir}" port=3D"${test.port}"
> > > > > > > > > > > > o=
utput=3D"${test.results}/tomcat4x.out"
> > > > > > > > > > > > t=
odir=3D"${test.results}/tomcat4x"
> > > > > > > > > > > > t=
mpdir=3D"${test.temp.dir}"
> > > > > > > > > > > > j=
vmArgs=3D"-DGG_HOME=3DC:/test"/>
> > > > > > > > > > > > </containerset>
> > > > > > > > > > > >
> > > > > > > > > > > > <formatter type=3D"brief" u=
sefile=3D"false"/>
> > > > > > > > > > > > <formatter type=3D"xml"/>
> > > > > > > > > > > >
> > > > > > > > > > > > <batchtest>
> > > > > > > > > > > > <fileset dir=3D"${t=
estsrc.dir}">
> > > > > > > > > > > > <include na=
me=3D"**/Test*.java"/>
> > > > > > > > > > > > <exclude na=
me=3D"**/Test*All.java"/>
> > > > > > > > > > > > </fileset>
> > > > > > > > > > > > </batchtest>
> > > > > > > > > > > >
> > > > > > > > > > > > </cactus>
> > > > > > > > > > > > <!-- Generate the JUnit reports -->
> > > > > > > > > > > >
> > > > > > > > > > > > <junitreport todir=3D"${test.result=
s}/tomcat4x">
> > > > > > > > > > > > <fileset dir=3D"${test.resu=
lts}/tomcat4x"
> > > > > > > > > > > > includes=
=3D"TEST-*.xml"/>
> > > > > > > > > > > > <report todir=3D"${test.res=
ults}/tomcat4x"
> > > > > > > > > > > > format=3D"f=
rames"/>
> > > > > > > > > > > > </junitreport>
> > > > > > > > > > > >
> > > > > > > > > > > > <fail if=3D"tests.failed">At least =
one test failed!</fail>
> > > > > > > > > > > >
> > > > > > > > > > > > </target>
> > > > > > > > > > > >
> > > > > > > > > > > > <target name=3D"coverage" description=3D"HTML cover=
age reports can be
> > > > > > > > > > > > found in build/coverage">
> > > > > > > > > > > >
> > > > > > > > > > > > <mkdir dir=3D"${test.results}/cover=
age"/>
> > > > > > > > > > > > <cobertura-report srcdir=3D"${src.d=
ir}"
> > > > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > > > >
> > > > > > > > > > > > <echo>
> > > > > > > > > > > > Cobertura reports have been=
generated.
> > > > > > > > > > > > The HTML report is ${test.r=
esults}/coverage/index.html
> > > > > > > > > > > > </echo>
> > > > > > > > > > > >
> > > > > > > > > > > > </target>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I'm getting 0% coverage for all tests.
> > > > > > > > > > > >
> > > > > > > > > > > > Is there a way to see if the classes have been inst=
rumented?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ---------------------------------------------------=
----
> > > > > > > > > > > > SF.Net email is Sponsored by the Better Software Co=
nference & EXPO
> > > > > > > > > > > > September 19-22, 2005 * San Francisco, CA * Develop=
ment Lifecycle Practices
> > > > > > > > > > > > Agile & Plan-Driven Development * Managing Projects=
& Teams * Testing & QA
> > > > > > > > > > > > Security * Process Improvement & Measurement * http=
://www.sqe.com/bsce5sf
> > > > > > > > > > > > _______________________________________________
> > > > > > > > > > > > Cobertura-devel mailing list
> > > > > > > > > > > > Cob...@li...
> > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobert=
ura-devel
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 21:55:13
|
If you put insturmented classes in serverclasses dir for Weblogic,
then they were treaten as part of web application.
You can try (at least for test) to instrument war - it should be
possible from Cobertura 1.5. Be aware that you will need cobertura.jar
(and dependend) in some tomcat lib subdirectory (or you can pack it
into war).
Grzegorz
On 8/23/05, yamaduc <ya...@gm...> wrote:
> I had this working before with weblogic just fine.
>=20
> I'm using tomcat now.
>=20
> With weblogic, i didn't need to put the instrumented classes in the
> war/ear file.
>=20
> I put the instrumented classes in the server's classpath and it worked fi=
ne.
>=20
> I'll try to put them in the war and see what happens.
>=20
> On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > Correct me if I'm wrong, cactus task work this way:
> >
> > - deploy war inside application container
> > - run tests on deployed application by cactus
> >
> > So if I get it right, classes packed into war are used when performing
> > tests. When you specifiy classpath inside cactus task, it specifies
> > classpath for test classes. So you need insturmented classes packed
> > into war, so that they are run during tests.
> >
> > Grzegorz
> >
> > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > so i should have the instrumented classes instead of the standard cla=
sses?
> > >
> > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > One more hit, maybe in created war you do not have instrumented cla=
sses?
> > > >
> > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > The date never changes.
> > > > >
> > > > >
> > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > Yes, it should be updated when tests are run but size will be t=
he
> > > > > > same. Check file change date.
> > > > > >
> > > > > > Reports does not update cobertura.ser.
> > > > > >
> > > > > > Grzegorz
> > > > > >
> > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > Is the cobertura.ser supposed to update during the report pro=
cess?
> > > > > > >
> > > > > > > I watched it after instrumentation, its 691k.
> > > > > > >
> > > > > > > After my tests run and the reports are executed, it's still t=
he same 691k.
> > > > > > >
> > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > Well, I tried passing it in as a runtime paramter to the jv=
m.
> > > > > > > >
> > > > > > > > Then the report task complained, couldn't find cobertura.se=
r.
> > > > > > > >
> > > > > > > > So, I added datafile to the ant task and the error message =
went away,
> > > > > > > > see ant target below.
> > > > > > > >
> > > > > > > > I only have one .ser file.
> > > > > > > > <cobertura-instrument datafile=3D"${test.dir}/cobertura.ser=
"
> > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > >
> > > > > > > >
> > > > > > > > <target name=3D"coverage" description=3D"HTML cover=
age reports can be
> > > > > > > > found in build/coverage">
> > > > > > > >
> > > > > > > > <mkdir dir=3D"${test.results}/coverage"/>
> > > > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > >
> > > > > > > > <echo>
> > > > > > > > Cobertura reports have been generat=
ed.
> > > > > > > > The HTML report is ${test.results}/=
coverage/index.html
> > > > > > > > </echo>
> > > > > > > >
> > > > > > > > </target>
> > > > > > > >
> > > > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > > > Hey,
> > > > > > > > >
> > > > > > > > > You probably do not set property net.sourceforge.cobertur=
a.datafile
> > > > > > > > > when running tests (I do not know how to do it inside cac=
tus task). Do
> > > > > > > > > you get additional cobertura.ser in directory where tests=
are run?
> > > > > > > > >
> > > > > > > > > Grzegorz
> > > > > > > > >
> > > > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > I have the following build script.
> > > > > > > > > >
> > > > > > > > > > <target name=3D"instrument" depends=3D"compile" descrip=
tion=3D"Add Cobertura
> > > > > > > > > > instrumentation">
> > > > > > > > > > <!-- instrument the application classes=
, writing the instrumented
> > > > > > > > > > classes into ${instrumented.classes}. -->
> > > > > > > > > >
> > > > > > > > > > <cobertura-instrument datafile=3D"${tes=
t.dir}/cobertura.ser"
> > > > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > > > <!-- Note that the following li=
ne causes instrument to ignore any
> > > > > > > > > > source line containing a r=
eference to log4j, for the purposes
> > > > > > > > > > of coverage reporting.=
-->
> > > > > > > > > > <ignore regex=3D"org.apache.log=
4j.*"/>
> > > > > > > > > >
> > > > > > > > > > <fileset dir=3D"${classes.dir}"=
>
> > > > > > > > > > <!-- instrument all the=
application classes, but don't instrument
> > > > > > > > > > the test classes. -->
> > > > > > > > > > <include name=3D"**/*.c=
lass"/>
> > > > > > > > > > <exclude name=3D"**/*Te=
st.class"/>
> > > > > > > > > > </fileset>
> > > > > > > > > > </cobertura-instrument>
> > > > > > > > > >
> > > > > > > > > > </target>
> > > > > > > > > >
> > > > > > > > > > <target name=3D"test" depends=3D"prepare.test.package" =
description=3D"Run
> > > > > > > > > > the tests on the defined container">
> > > > > > > > > > <!-- Run the tests -->
> > > > > > > > > > <mkdir dir=3D"${test.results}/tomcat4x"=
/>
> > > > > > > > > > <cactus warfile=3D"${test-war.dir}/${ap=
p.name}-${app.version}.war"
> > > > > > > > > > fork=3D"yes" failureproperty=3D"tests.failed" haltonerr=
or=3D"true">
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <!-- Configure the cactus task =
for logging -->
> > > > > > > > > > <cactusproperty server=3D"false=
"
> > > > > > > > > > propertiesFile=3D"${met=
a.dir}/${configtype}/test/logging_client.properties"/>
> > > > > > > > > > <cactusproperty server=3D"true"
> > > > > > > > > > propertiesFile=3D"${met=
a.dir}/${configtype}/test/logging_server.properties"/>
> > > > > > > > > >
> > > > > > > > > > <!-- Additional jars that will =
be added to the classpath used to start the
> > > > > > > > > > container (in addition=
to the container jars themseleves which are
> > > > > > > > > > automatically added by=
the <cactus> task -->
> > > > > > > > > > <containerclasspath>
> > > > > > > > > > <pathelement path=3D"${=
test-props.dir}"/>
> > > > > > > > > > </containerclasspath>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <classpath>
> > > > > > > > > > <pathelement path=3D"${=
instrumented.classes}"/>
> > > > > > > > > > <pathelement path=3D"${=
classes.dir}"/>
> > > > > > > > > > <pathelement location=
=3D"${test-lib.dir}/my-tests.jar"/>
> > > > > > > > > > <path refid=3D"project.=
classpath"/>
> > > > > > > > > > </classpath>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > <containerset>
> > > > > > > > > > <tomcat4x if=3D"tomcat-=
dist.dir"
> > > > > > > > > > dir=
=3D"${tomcat-dist.dir}" port=3D"${test.port}"
> > > > > > > > > > outpu=
t=3D"${test.results}/tomcat4x.out"
> > > > > > > > > > todir=
=3D"${test.results}/tomcat4x"
> > > > > > > > > > tmpdi=
r=3D"${test.temp.dir}"
> > > > > > > > > > jvmAr=
gs=3D"-DGG_HOME=3DC:/test"/>
> > > > > > > > > > </containerset>
> > > > > > > > > >
> > > > > > > > > > <formatter type=3D"brief" usefi=
le=3D"false"/>
> > > > > > > > > > <formatter type=3D"xml"/>
> > > > > > > > > >
> > > > > > > > > > <batchtest>
> > > > > > > > > > <fileset dir=3D"${tests=
rc.dir}">
> > > > > > > > > > <include name=
=3D"**/Test*.java"/>
> > > > > > > > > > <exclude name=
=3D"**/Test*All.java"/>
> > > > > > > > > > </fileset>
> > > > > > > > > > </batchtest>
> > > > > > > > > >
> > > > > > > > > > </cactus>
> > > > > > > > > > <!-- Generate the JUnit reports -->
> > > > > > > > > >
> > > > > > > > > > <junitreport todir=3D"${test.results}/t=
omcat4x">
> > > > > > > > > > <fileset dir=3D"${test.results}=
/tomcat4x"
> > > > > > > > > > includes=3D"TE=
ST-*.xml"/>
> > > > > > > > > > <report todir=3D"${test.results=
}/tomcat4x"
> > > > > > > > > > format=3D"frame=
s"/>
> > > > > > > > > > </junitreport>
> > > > > > > > > >
> > > > > > > > > > <fail if=3D"tests.failed">At least one =
test failed!</fail>
> > > > > > > > > >
> > > > > > > > > > </target>
> > > > > > > > > >
> > > > > > > > > > <target name=3D"coverage" description=3D"HTML coverage =
reports can be
> > > > > > > > > > found in build/coverage">
> > > > > > > > > >
> > > > > > > > > > <mkdir dir=3D"${test.results}/coverage"=
/>
> > > > > > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > > > >
> > > > > > > > > > <echo>
> > > > > > > > > > Cobertura reports have been gen=
erated.
> > > > > > > > > > The HTML report is ${test.resul=
ts}/coverage/index.html
> > > > > > > > > > </echo>
> > > > > > > > > >
> > > > > > > > > > </target>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I'm getting 0% coverage for all tests.
> > > > > > > > > >
> > > > > > > > > > Is there a way to see if the classes have been instrume=
nted?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > -------------------------------------------------------
> > > > > > > > > > SF.Net email is Sponsored by the Better Software Confer=
ence & EXPO
> > > > > > > > > > September 19-22, 2005 * San Francisco, CA * Development=
Lifecycle Practices
> > > > > > > > > > Agile & Plan-Driven Development * Managing Projects & T=
eams * Testing & QA
> > > > > > > > > > Security * Process Improvement & Measurement * http://w=
ww.sqe.com/bsce5sf
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Cobertura-devel mailing list
> > > > > > > > > > Cob...@li...
> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-=
devel
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 21:25:39
|
Correct me if I'm wrong, cactus task work this way:
- deploy war inside application container
- run tests on deployed application by cactus
So if I get it right, classes packed into war are used when performing
tests. When you specifiy classpath inside cactus task, it specifies
classpath for test classes. So you need insturmented classes packed
into war, so that they are run during tests.
Grzegorz
On 8/23/05, yamaduc <ya...@gm...> wrote:
> so i should have the instrumented classes instead of the standard classes=
?
>=20
> On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > One more hit, maybe in created war you do not have instrumented classes=
?
> >
> > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > The date never changes.
> > >
> > >
> > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > Yes, it should be updated when tests are run but size will be the
> > > > same. Check file change date.
> > > >
> > > > Reports does not update cobertura.ser.
> > > >
> > > > Grzegorz
> > > >
> > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > Is the cobertura.ser supposed to update during the report process=
?
> > > > >
> > > > > I watched it after instrumentation, its 691k.
> > > > >
> > > > > After my tests run and the reports are executed, it's still the s=
ame 691k.
> > > > >
> > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > Well, I tried passing it in as a runtime paramter to the jvm.
> > > > > >
> > > > > > Then the report task complained, couldn't find cobertura.ser.
> > > > > >
> > > > > > So, I added datafile to the ant task and the error message went=
away,
> > > > > > see ant target below.
> > > > > >
> > > > > > I only have one .ser file.
> > > > > > <cobertura-instrument datafile=3D"${test.dir}/cobertura.ser"
> > > > > > todir=3D"${instrumented.classes}">
> > > > > >
> > > > > >
> > > > > > <target name=3D"coverage" description=3D"HTML coverage =
reports can be
> > > > > > found in build/coverage">
> > > > > >
> > > > > > <mkdir dir=3D"${test.results}/coverage"/>
> > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > destdir=3D"${test.results}/coverage"
> > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > >
> > > > > > <echo>
> > > > > > Cobertura reports have been generated.
> > > > > > The HTML report is ${test.results}/cove=
rage/index.html
> > > > > > </echo>
> > > > > >
> > > > > > </target>
> > > > > >
> > > > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > > > Hey,
> > > > > > >
> > > > > > > You probably do not set property net.sourceforge.cobertura.da=
tafile
> > > > > > > when running tests (I do not know how to do it inside cactus =
task). Do
> > > > > > > you get additional cobertura.ser in directory where tests are=
run?
> > > > > > >
> > > > > > > Grzegorz
> > > > > > >
> > > > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I have the following build script.
> > > > > > > >
> > > > > > > > <target name=3D"instrument" depends=3D"compile" description=
=3D"Add Cobertura
> > > > > > > > instrumentation">
> > > > > > > > <!-- instrument the application classes, wr=
iting the instrumented
> > > > > > > > classes into ${instrumented.classes}. -->
> > > > > > > >
> > > > > > > > <cobertura-instrument datafile=3D"${test.di=
r}/cobertura.ser"
> > > > > > > > todir=3D"${instrumented.classes}">
> > > > > > > > <!-- Note that the following line c=
auses instrument to ignore any
> > > > > > > > source line containing a refer=
ence to log4j, for the purposes
> > > > > > > > of coverage reporting. -->
> > > > > > > > <ignore regex=3D"org.apache.log4j.*=
"/>
> > > > > > > >
> > > > > > > > <fileset dir=3D"${classes.dir}">
> > > > > > > > <!-- instrument all the app=
lication classes, but don't instrument
> > > > > > > > the test classes. -->
> > > > > > > > <include name=3D"**/*.class=
"/>
> > > > > > > > <exclude name=3D"**/*Test.c=
lass"/>
> > > > > > > > </fileset>
> > > > > > > > </cobertura-instrument>
> > > > > > > >
> > > > > > > > </target>
> > > > > > > >
> > > > > > > > <target name=3D"test" depends=3D"prepare.test.package" desc=
ription=3D"Run
> > > > > > > > the tests on the defined container">
> > > > > > > > <!-- Run the tests -->
> > > > > > > > <mkdir dir=3D"${test.results}/tomcat4x"/>
> > > > > > > > <cactus warfile=3D"${test-war.dir}/${app.na=
me}-${app.version}.war"
> > > > > > > > fork=3D"yes" failureproperty=3D"tests.failed" haltonerror=
=3D"true">
> > > > > > > >
> > > > > > > >
> > > > > > > > <!-- Configure the cactus task for =
logging -->
> > > > > > > > <cactusproperty server=3D"false"
> > > > > > > > propertiesFile=3D"${meta.di=
r}/${configtype}/test/logging_client.properties"/>
> > > > > > > > <cactusproperty server=3D"true"
> > > > > > > > propertiesFile=3D"${meta.di=
r}/${configtype}/test/logging_server.properties"/>
> > > > > > > >
> > > > > > > > <!-- Additional jars that will be a=
dded to the classpath used to start the
> > > > > > > > container (in addition to =
the container jars themseleves which are
> > > > > > > > automatically added by the=
<cactus> task -->
> > > > > > > > <containerclasspath>
> > > > > > > > <pathelement path=3D"${test=
-props.dir}"/>
> > > > > > > > </containerclasspath>
> > > > > > > >
> > > > > > > >
> > > > > > > > <classpath>
> > > > > > > > <pathelement path=3D"${inst=
rumented.classes}"/>
> > > > > > > > <pathelement path=3D"${clas=
ses.dir}"/>
> > > > > > > > <pathelement location=3D"${=
test-lib.dir}/my-tests.jar"/>
> > > > > > > > <path refid=3D"project.clas=
spath"/>
> > > > > > > > </classpath>
> > > > > > > >
> > > > > > > >
> > > > > > > > <containerset>
> > > > > > > > <tomcat4x if=3D"tomcat-dist=
.dir"
> > > > > > > > dir=3D"${=
tomcat-dist.dir}" port=3D"${test.port}"
> > > > > > > > output=3D=
"${test.results}/tomcat4x.out"
> > > > > > > > todir=3D"=
${test.results}/tomcat4x"
> > > > > > > > tmpdir=3D=
"${test.temp.dir}"
> > > > > > > > jvmArgs=
=3D"-DGG_HOME=3DC:/test"/>
> > > > > > > > </containerset>
> > > > > > > >
> > > > > > > > <formatter type=3D"brief" usefile=
=3D"false"/>
> > > > > > > > <formatter type=3D"xml"/>
> > > > > > > >
> > > > > > > > <batchtest>
> > > > > > > > <fileset dir=3D"${testsrc.d=
ir}">
> > > > > > > > <include name=3D"**=
/Test*.java"/>
> > > > > > > > <exclude name=3D"**=
/Test*All.java"/>
> > > > > > > > </fileset>
> > > > > > > > </batchtest>
> > > > > > > >
> > > > > > > > </cactus>
> > > > > > > > <!-- Generate the JUnit reports -->
> > > > > > > >
> > > > > > > > <junitreport todir=3D"${test.results}/tomca=
t4x">
> > > > > > > > <fileset dir=3D"${test.results}/tom=
cat4x"
> > > > > > > > includes=3D"TEST-*=
.xml"/>
> > > > > > > > <report todir=3D"${test.results}/to=
mcat4x"
> > > > > > > > format=3D"frames"/>
> > > > > > > > </junitreport>
> > > > > > > >
> > > > > > > > <fail if=3D"tests.failed">At least one test=
failed!</fail>
> > > > > > > >
> > > > > > > > </target>
> > > > > > > >
> > > > > > > > <target name=3D"coverage" description=3D"HTML coverage repo=
rts can be
> > > > > > > > found in build/coverage">
> > > > > > > >
> > > > > > > > <mkdir dir=3D"${test.results}/coverage"/>
> > > > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > > > destdir=3D"${test.results}/coverage"
> > > > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > > > >
> > > > > > > > <echo>
> > > > > > > > Cobertura reports have been generat=
ed.
> > > > > > > > The HTML report is ${test.results}/=
coverage/index.html
> > > > > > > > </echo>
> > > > > > > >
> > > > > > > > </target>
> > > > > > > >
> > > > > > > >
> > > > > > > > I'm getting 0% coverage for all tests.
> > > > > > > >
> > > > > > > > Is there a way to see if the classes have been instrumented=
?
> > > > > > > >
> > > > > > > >
> > > > > > > > -------------------------------------------------------
> > > > > > > > SF.Net email is Sponsored by the Better Software Conference=
& EXPO
> > > > > > > > September 19-22, 2005 * San Francisco, CA * Development Lif=
ecycle Practices
> > > > > > > > Agile & Plan-Driven Development * Managing Projects & Teams=
* Testing & QA
> > > > > > > > Security * Process Improvement & Measurement * http://www.s=
qe.com/bsce5sf
> > > > > > > > _______________________________________________
> > > > > > > > Cobertura-devel mailing list
> > > > > > > > Cob...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-deve=
l
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 21:15:14
|
One more hit, maybe in created war you do not have instrumented classes?
On 8/23/05, yamaduc <ya...@gm...> wrote:
> The date never changes.
>=20
>=20
> On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > Yes, it should be updated when tests are run but size will be the
> > same. Check file change date.
> >
> > Reports does not update cobertura.ser.
> >
> > Grzegorz
> >
> > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > Is the cobertura.ser supposed to update during the report process?
> > >
> > > I watched it after instrumentation, its 691k.
> > >
> > > After my tests run and the reports are executed, it's still the same =
691k.
> > >
> > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > Well, I tried passing it in as a runtime paramter to the jvm.
> > > >
> > > > Then the report task complained, couldn't find cobertura.ser.
> > > >
> > > > So, I added datafile to the ant task and the error message went awa=
y,
> > > > see ant target below.
> > > >
> > > > I only have one .ser file.
> > > > <cobertura-instrument datafile=3D"${test.dir}/cobertura.ser"
> > > > todir=3D"${instrumented.classes}">
> > > >
> > > >
> > > > <target name=3D"coverage" description=3D"HTML coverage repo=
rts can be
> > > > found in build/coverage">
> > > >
> > > > <mkdir dir=3D"${test.results}/coverage"/>
> > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > destdir=3D"${test.results}/coverage"
> > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > >
> > > > <echo>
> > > > Cobertura reports have been generated.
> > > > The HTML report is ${test.results}/coverage=
/index.html
> > > > </echo>
> > > >
> > > > </target>
> > > >
> > > > On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > > > > Hey,
> > > > >
> > > > > You probably do not set property net.sourceforge.cobertura.datafi=
le
> > > > > when running tests (I do not know how to do it inside cactus task=
). Do
> > > > > you get additional cobertura.ser in directory where tests are run=
?
> > > > >
> > > > > Grzegorz
> > > > >
> > > > > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I have the following build script.
> > > > > >
> > > > > > <target name=3D"instrument" depends=3D"compile" description=3D"=
Add Cobertura
> > > > > > instrumentation">
> > > > > > <!-- instrument the application classes, writin=
g the instrumented
> > > > > > classes into ${instrumented.classes}. -->
> > > > > >
> > > > > > <cobertura-instrument datafile=3D"${test.dir}/c=
obertura.ser"
> > > > > > todir=3D"${instrumented.classes}">
> > > > > > <!-- Note that the following line cause=
s instrument to ignore any
> > > > > > source line containing a reference=
to log4j, for the purposes
> > > > > > of coverage reporting. -->
> > > > > > <ignore regex=3D"org.apache.log4j.*"/>
> > > > > >
> > > > > > <fileset dir=3D"${classes.dir}">
> > > > > > <!-- instrument all the applica=
tion classes, but don't instrument
> > > > > > the test classes. -->
> > > > > > <include name=3D"**/*.class"/>
> > > > > > <exclude name=3D"**/*Test.class=
"/>
> > > > > > </fileset>
> > > > > > </cobertura-instrument>
> > > > > >
> > > > > > </target>
> > > > > >
> > > > > > <target name=3D"test" depends=3D"prepare.test.package" descript=
ion=3D"Run
> > > > > > the tests on the defined container">
> > > > > > <!-- Run the tests -->
> > > > > > <mkdir dir=3D"${test.results}/tomcat4x"/>
> > > > > > <cactus warfile=3D"${test-war.dir}/${app.name}-=
${app.version}.war"
> > > > > > fork=3D"yes" failureproperty=3D"tests.failed" haltonerror=3D"tr=
ue">
> > > > > >
> > > > > >
> > > > > > <!-- Configure the cactus task for logg=
ing -->
> > > > > > <cactusproperty server=3D"false"
> > > > > > propertiesFile=3D"${meta.dir}/$=
{configtype}/test/logging_client.properties"/>
> > > > > > <cactusproperty server=3D"true"
> > > > > > propertiesFile=3D"${meta.dir}/$=
{configtype}/test/logging_server.properties"/>
> > > > > >
> > > > > > <!-- Additional jars that will be added=
to the classpath used to start the
> > > > > > container (in addition to the =
container jars themseleves which are
> > > > > > automatically added by the <ca=
ctus> task -->
> > > > > > <containerclasspath>
> > > > > > <pathelement path=3D"${test-pro=
ps.dir}"/>
> > > > > > </containerclasspath>
> > > > > >
> > > > > >
> > > > > > <classpath>
> > > > > > <pathelement path=3D"${instrume=
nted.classes}"/>
> > > > > > <pathelement path=3D"${classes.=
dir}"/>
> > > > > > <pathelement location=3D"${test=
-lib.dir}/my-tests.jar"/>
> > > > > > <path refid=3D"project.classpat=
h"/>
> > > > > > </classpath>
> > > > > >
> > > > > >
> > > > > > <containerset>
> > > > > > <tomcat4x if=3D"tomcat-dist.dir=
"
> > > > > > dir=3D"${tomc=
at-dist.dir}" port=3D"${test.port}"
> > > > > > output=3D"${t=
est.results}/tomcat4x.out"
> > > > > > todir=3D"${te=
st.results}/tomcat4x"
> > > > > > tmpdir=3D"${t=
est.temp.dir}"
> > > > > > jvmArgs=3D"-D=
GG_HOME=3DC:/test"/>
> > > > > > </containerset>
> > > > > >
> > > > > > <formatter type=3D"brief" usefile=3D"fa=
lse"/>
> > > > > > <formatter type=3D"xml"/>
> > > > > >
> > > > > > <batchtest>
> > > > > > <fileset dir=3D"${testsrc.dir}"=
>
> > > > > > <include name=3D"**/Tes=
t*.java"/>
> > > > > > <exclude name=3D"**/Tes=
t*All.java"/>
> > > > > > </fileset>
> > > > > > </batchtest>
> > > > > >
> > > > > > </cactus>
> > > > > > <!-- Generate the JUnit reports -->
> > > > > >
> > > > > > <junitreport todir=3D"${test.results}/tomcat4x"=
>
> > > > > > <fileset dir=3D"${test.results}/tomcat4=
x"
> > > > > > includes=3D"TEST-*.xml=
"/>
> > > > > > <report todir=3D"${test.results}/tomcat=
4x"
> > > > > > format=3D"frames"/>
> > > > > > </junitreport>
> > > > > >
> > > > > > <fail if=3D"tests.failed">At least one test fai=
led!</fail>
> > > > > >
> > > > > > </target>
> > > > > >
> > > > > > <target name=3D"coverage" description=3D"HTML coverage reports =
can be
> > > > > > found in build/coverage">
> > > > > >
> > > > > > <mkdir dir=3D"${test.results}/coverage"/>
> > > > > > <cobertura-report srcdir=3D"${src.dir}"
> > > > > > destdir=3D"${test.results}/coverage"
> > > > > > datafile=3D"${test.dir}/cobertura.ser"/>
> > > > > >
> > > > > > <echo>
> > > > > > Cobertura reports have been generated.
> > > > > > The HTML report is ${test.results}/cove=
rage/index.html
> > > > > > </echo>
> > > > > >
> > > > > > </target>
> > > > > >
> > > > > >
> > > > > > I'm getting 0% coverage for all tests.
> > > > > >
> > > > > > Is there a way to see if the classes have been instrumented?
> > > > > >
> > > > > >
> > > > > > -------------------------------------------------------
> > > > > > SF.Net email is Sponsored by the Better Software Conference & E=
XPO
> > > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecyc=
le Practices
> > > > > > Agile & Plan-Driven Development * Managing Projects & Teams * T=
esting & QA
> > > > > > Security * Process Improvement & Measurement * http://www.sqe.c=
om/bsce5sf
> > > > > > _______________________________________________
> > > > > > Cobertura-devel mailing list
> > > > > > Cob...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> > > > > >
> > > > >
> > > >
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 20:47:15
|
OK. In ant snippents that you presented there was no such option. Just
to be sure, you are not talking about specyfying this option to ant?
Just when launching tests (in appropriate task, like junit or cactus),
am i right?
Grzegorz=20
On 8/23/05, yamaduc <ya...@gm...> wrote:
> -Dnet.sourceforge.cobertura.datafile=3D${test.dir}/cobertura.ser
>=20
> I have that.
>=20
> On 8/23/05, Grzegorz Lukasik <ha...@gm...> wrote:
> > Hi
> >
> > > -Dcom.jcoverage.instrumentation.interval=3D30
> > > -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir>
> >
> > These options are not valid.
> >
> > > -Dnet.sourceforge.cobertura.rawcoverage.dir
> >
> > Maybe you mean net.sourceforge.cobertura.datafile, it should point to
> > cobertura.ser created during instrumentation.
> >
> > Grzegorz
> >
> > On 8/23/05, yamaduc <ya...@gm...> wrote:
> > > Are these valid jvm args?
> > >
> > > -Dcom.jcoverage.instrumentation.interval=3D30
> > > -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir>
> > >
> > > What directory is -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some
> > > dir> supposed to point to?
> > >
> > > Thanks
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pra=
ctices
> > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing=
& QA
> > > Security * Process Improvement & Measurement * http://www.sqe.com/bsc=
e5sf
> > > _______________________________________________
> > > Cobertura-devel mailing list
> > > Cob...@li...
> > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel
> > >
> >
>
|
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 19:51:38
|
Hi > -Dcom.jcoverage.instrumentation.interval=3D30 > -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir> These options are not valid. > -Dnet.sourceforge.cobertura.rawcoverage.dir Maybe you mean net.sourceforge.cobertura.datafile, it should point to cobertura.ser created during instrumentation. Grzegorz On 8/23/05, yamaduc <ya...@gm...> wrote: > Are these valid jvm args? >=20 > -Dcom.jcoverage.instrumentation.interval=3D30 > -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir> >=20 > What directory is -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some > dir> supposed to point to? >=20 > Thanks >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Cobertura-devel mailing list > Cob...@li... > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-23 19:45:13
|
Hey,
You probably do not set property net.sourceforge.cobertura.datafile
when running tests (I do not know how to do it inside cactus task). Do
you get additional cobertura.ser in directory where tests are run?
Grzegorz
On 8/23/05, yamaduc <ya...@gm...> wrote:
> Hi all,
>=20
> I have the following build script.
>=20
> <target name=3D"instrument" depends=3D"compile" description=3D"Add Cobert=
ura
> instrumentation">
> <!-- instrument the application classes, writing the inst=
rumented
> classes into ${instrumented.classes}. -->
>=20
> <cobertura-instrument datafile=3D"${test.dir}/cobertura.s=
er"
> todir=3D"${instrumented.classes}">
> <!-- Note that the following line causes instrume=
nt to ignore any
> source line containing a reference to log4j,=
for the purposes
> of coverage reporting. -->
> <ignore regex=3D"org.apache.log4j.*"/>
>=20
> <fileset dir=3D"${classes.dir}">
> <!-- instrument all the application class=
es, but don't instrument
> the test classes. -->
> <include name=3D"**/*.class"/>
> <exclude name=3D"**/*Test.class"/>
> </fileset>
> </cobertura-instrument>
>=20
> </target>
>=20
> <target name=3D"test" depends=3D"prepare.test.package" description=3D"Run
> the tests on the defined container">
> <!-- Run the tests -->
> <mkdir dir=3D"${test.results}/tomcat4x"/>
> <cactus warfile=3D"${test-war.dir}/${app.name}-${app.vers=
ion}.war"
> fork=3D"yes" failureproperty=3D"tests.failed" haltonerror=3D"true">
>=20
>=20
> <!-- Configure the cactus task for logging -->
> <cactusproperty server=3D"false"
> propertiesFile=3D"${meta.dir}/${configtyp=
e}/test/logging_client.properties"/>
> <cactusproperty server=3D"true"
> propertiesFile=3D"${meta.dir}/${configtyp=
e}/test/logging_server.properties"/>
>=20
> <!-- Additional jars that will be added to the cl=
asspath used to start the
> container (in addition to the container =
jars themseleves which are
> automatically added by the <cactus> task=
-->
> <containerclasspath>
> <pathelement path=3D"${test-props.dir}"/>
> </containerclasspath>
>=20
>=20
> <classpath>
> <pathelement path=3D"${instrumented.class=
es}"/>
> <pathelement path=3D"${classes.dir}"/>
> <pathelement location=3D"${test-lib.dir}/=
my-tests.jar"/>
> <path refid=3D"project.classpath"/>
> </classpath>
>=20
>=20
> <containerset>
> <tomcat4x if=3D"tomcat-dist.dir"
> dir=3D"${tomcat-dist.di=
r}" port=3D"${test.port}"
> output=3D"${test.result=
s}/tomcat4x.out"
> todir=3D"${test.results=
}/tomcat4x"
> tmpdir=3D"${test.temp.d=
ir}"
> jvmArgs=3D"-DGG_HOME=3D=
C:/test"/>
> </containerset>
>=20
> <formatter type=3D"brief" usefile=3D"false"/>
> <formatter type=3D"xml"/>
>=20
> <batchtest>
> <fileset dir=3D"${testsrc.dir}">
> <include name=3D"**/Test*.java"/>
> <exclude name=3D"**/Test*All.java=
"/>
> </fileset>
> </batchtest>
>=20
> </cactus>
> <!-- Generate the JUnit reports -->
>=20
> <junitreport todir=3D"${test.results}/tomcat4x">
> <fileset dir=3D"${test.results}/tomcat4x"
> includes=3D"TEST-*.xml"/>
> <report todir=3D"${test.results}/tomcat4x"
> format=3D"frames"/>
> </junitreport>
>=20
> <fail if=3D"tests.failed">At least one test failed!</fail=
>
>=20
> </target>
>=20
> <target name=3D"coverage" description=3D"HTML coverage reports can be
> found in build/coverage">
>=20
> <mkdir dir=3D"${test.results}/coverage"/>
> <cobertura-report srcdir=3D"${src.dir}"
> destdir=3D"${test.results}/coverage"
> datafile=3D"${test.dir}/cobertura.ser"/>
>=20
> <echo>
> Cobertura reports have been generated.
> The HTML report is ${test.results}/coverage/index=
.html
> </echo>
>=20
> </target>
>=20
>=20
> I'm getting 0% coverage for all tests.
>=20
> Is there a way to see if the classes have been instrumented?
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
|
|
From: Carlos S. <car...@gm...> - 2005-08-23 19:07:17
|
It's not automatic, and won't probably be. The plugin can be improved to allow overriding it as it is the clover plugin IIRC. I've upgraded the plugin in CVS to use cobertura 1.6 and I've uploaded the cobertura 1.6 jar to ibiblio, so in a few hours you should be able to build it from CVS. Any help in mantaining and improving the plugin is appreciated. http://maven-plugins.sourceforge.net/maven-cobertura-plugin/. Regards Carlos Sanchez On 8/23/05, Mark Doliner <Mar...@sa...> wrote: > I believe that should be handled by the maven cobertura plugin people. I= guess it's possible that its automatic... but I would guess not. > http://maven-plugins.sourceforge.net/maven-cobertura-plugin/ > -Mark >=20 > > -----Original Message----- > > From: Elliotte Harold [mailto:el...@me...] > > Sent: Tuesday, August 23, 2005 7:27 AM > > To: Mark Doliner > > Cc: cob...@li... > > Subject: Cobertura 1.6 and Maven > > > > This is perhaps more a maven question than a Cobertura one. > > Is the maven > > plugin going to pick up this new version automatically, or is > > an upgrade > > to that required as well? > > > > -- > > Elliotte Rusty Harold el...@me... > > XML in a Nutshell 3rd Edition Just Published! > > http://www.cafeconleche.org/books/xian3/ > > http://www.amazon.com/exec/obidos/ISBN=3D0596007647/cafeaulaitA/ > > ref=3Dnosim > > > |
|
From: yamaduc <ya...@gm...> - 2005-08-23 18:34:43
|
Are these valid jvm args? -Dcom.jcoverage.instrumentation.interval=3D30 -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir> What directory is -Dnet.sourceforge.cobertura.rawcoverage.dir=3D<some dir> supposed to point to? Thanks |
|
From: yamaduc <ya...@gm...> - 2005-08-23 18:24:09
|
Hi all,
I have the following build script.
<target name=3D"instrument" depends=3D"compile" description=3D"Add Cobertur=
a
instrumentation">
=09=09<!-- instrument the application classes, writing the instrumented
classes into ${instrumented.classes}. -->
=20
=09=09<cobertura-instrument datafile=3D"${test.dir}/cobertura.ser"
todir=3D"${instrumented.classes}">
=09=09=09<!-- Note that the following line causes instrument to ignore any
=09=09=09 source line containing a reference to log4j, for the purposes
=09=09=09=09 of coverage reporting. -->
=09=09=09<ignore regex=3D"org.apache.log4j.*"/>
=20
=09=09=09<fileset dir=3D"${classes.dir}">
=09=09=09=09<!-- instrument all the application classes, but don't instrume=
nt
the test classes. -->
=09=09=09=09<include name=3D"**/*.class"/>
=09=09=09=09<exclude name=3D"**/*Test.class"/>
=09=09=09</fileset>
=09=09</cobertura-instrument>
</target>
<target name=3D"test" depends=3D"prepare.test.package" description=3D"Run
the tests on the defined container">
=09=09<!-- Run the tests -->
=09=09<mkdir dir=3D"${test.results}/tomcat4x"/>
=09=09<cactus warfile=3D"${test-war.dir}/${app.name}-${app.version}.war"
fork=3D"yes" failureproperty=3D"tests.failed" haltonerror=3D"true">
=09=09=09<!-- Configure the cactus task for logging -->
=09=09=09<cactusproperty server=3D"false"
=09=09=09=09propertiesFile=3D"${meta.dir}/${configtype}/test/logging_client=
.properties"/>
=09=09=09<cactusproperty server=3D"true"
=09=09=09=09propertiesFile=3D"${meta.dir}/${configtype}/test/logging_server=
.properties"/>
=09=09=09<!-- Additional jars that will be added to the classpath used to s=
tart the
=09=09=09=09 container (in addition to the container jars themseleves which=
are
=09=09=09=09 automatically added by the <cactus> task -->
=09=09=09<containerclasspath>
=09=09=09=09<pathelement path=3D"${test-props.dir}"/>
=09=09=09</containerclasspath>
=09=09=09
=09=09=09<classpath>
=09=09=09=09<pathelement path=3D"${instrumented.classes}"/>
=09=09=09=09<pathelement path=3D"${classes.dir}"/>
=09=09=09=09<pathelement location=3D"${test-lib.dir}/my-tests.jar"/>
=09=09=09=09<path refid=3D"project.classpath"/>
=09=09=09</classpath>
=09
=09=09=09<containerset>
=09=09=09=09<tomcat4x if=3D"tomcat-dist.dir"
=09=09=09=09=09=09 dir=3D"${tomcat-dist.dir}" port=3D"${test.port}"
=09=09=09=09=09=09 output=3D"${test.results}/tomcat4x.out"
=09=09=09=09=09=09 todir=3D"${test.results}/tomcat4x"
=09=09=09=09=09=09 tmpdir=3D"${test.temp.dir}"
=09=09=09=09=09=09 jvmArgs=3D"-DGG_HOME=3DC:/test"/>
=09=09=09</containerset>
=09=09=09<formatter type=3D"brief" usefile=3D"false"/>
=09=09=09<formatter type=3D"xml"/>
=09=09=09<batchtest>
=09=09=09=09<fileset dir=3D"${testsrc.dir}">
=09=09=09=09=09<include name=3D"**/Test*.java"/>
=09=09=09=09=09<exclude name=3D"**/Test*All.java"/>
=09=09=09=09</fileset>
=09=09=09</batchtest>
=09=09</cactus>
<!-- Generate the JUnit reports -->
=20
=09=09<junitreport todir=3D"${test.results}/tomcat4x">
=09=09=09<fileset dir=3D"${test.results}/tomcat4x"
=09=09=09=09=09 includes=3D"TEST-*.xml"/>
=09=09=09<report todir=3D"${test.results}/tomcat4x"
=09=09=09=09=09format=3D"frames"/>
=09=09</junitreport>
=09=09<fail if=3D"tests.failed">At least one test failed!</fail>
=09</target>
<target name=3D"coverage" description=3D"HTML coverage reports can be
found in build/coverage">
=09 =20
=09=09<mkdir dir=3D"${test.results}/coverage"/>
=09=09<cobertura-report srcdir=3D"${src.dir}"
destdir=3D"${test.results}/coverage"
datafile=3D"${test.dir}/cobertura.ser"/>
=09=09<echo>
=09=09=09Cobertura reports have been generated.
=09=09=09The HTML report is ${test.results}/coverage/index.html
=09=09</echo>
</target>
I'm getting 0% coverage for all tests.
Is there a way to see if the classes have been instrumented?
|
|
From: Mark D. <Mar...@sa...> - 2005-08-23 14:19:41
|
SSBiZWxpZXZlIHRoYXQgc2hvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIG1hdmVuIGNvYmVydHVyYSBw bHVnaW4gcGVvcGxlLiAgSSBndWVzcyBpdCdzIHBvc3NpYmxlIHRoYXQgaXRzIGF1dG9tYXRpYy4u LiBidXQgSSB3b3VsZCBndWVzcyBub3QuDQpodHRwOi8vbWF2ZW4tcGx1Z2lucy5zb3VyY2Vmb3Jn ZS5uZXQvbWF2ZW4tY29iZXJ0dXJhLXBsdWdpbi8NCi1NYXJrIA0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEVsbGlvdHRlIEhhcm9sZCBbbWFpbHRvOmVsaGFyb0BtZXRh bGFiLnVuYy5lZHVdIA0KPiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjMsIDIwMDUgNzoyNyBBTQ0K PiBUbzogTWFyayBEb2xpbmVyDQo+IENjOiBjb2JlcnR1cmEtZGV2ZWxAbGlzdHMuc291cmNlZm9y Z2UubmV0DQo+IFN1YmplY3Q6IENvYmVydHVyYSAxLjYgYW5kIE1hdmVuDQo+IA0KPiBUaGlzIGlz IHBlcmhhcHMgbW9yZSBhIG1hdmVuIHF1ZXN0aW9uIHRoYW4gYSBDb2JlcnR1cmEgb25lLiANCj4g SXMgdGhlIG1hdmVuIA0KPiBwbHVnaW4gZ29pbmcgdG8gcGljayB1cCB0aGlzIG5ldyB2ZXJzaW9u IGF1dG9tYXRpY2FsbHksIG9yIGlzIA0KPiBhbiB1cGdyYWRlIA0KPiB0byB0aGF0IHJlcXVpcmVk IGFzIHdlbGw/DQo+IA0KPiAtLSANCj4g77u/RWxsaW90dGUgUnVzdHkgSGFyb2xkICBlbGhhcm9A bWV0YWxhYi51bmMuZWR1DQo+IFhNTCBpbiBhIE51dHNoZWxsIDNyZCBFZGl0aW9uIEp1c3QgUHVi bGlzaGVkIQ0KPiBodHRwOi8vd3d3LmNhZmVjb25sZWNoZS5vcmcvYm9va3MveGlhbjMvDQo+IGh0 dHA6Ly93d3cuYW1hem9uLmNvbS9leGVjL29iaWRvcy9JU0JOPTA1OTYwMDc2NDcvY2FmZWF1bGFp dEEvDQo+IHJlZj1ub3NpbQ0KPiANCg== |
|
From: Elliotte H. <el...@me...> - 2005-08-23 11:27:22
|
This is perhaps more a maven question than a Cobertura one. Is the maven plugin going to pick up this new version automatically, or is an upgrade to that required as well? -- Elliotte Rusty Harold el...@me... XML in a Nutshell 3rd Edition Just Published! http://www.cafeconleche.org/books/xian3/ http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim |
|
From: Mark D. <Mar...@sa...> - 2005-08-22 17:57:17
|
The email subject says it all. If you're on cobertura-commits and wondering what happened, first we lef= t James Seigel's name out of the ChangeLog, even though I believe he hel= ped with some of the cobertura-report changes (or at least the unit test= s for the changes?) Second, the build.xml wasn't including src-2 in the= tarballs/zip files, so the source distributables failed to build. Thir= d, and maybe this was just my computer, but I was seeing a weird error w= hen trying to run the simple example from the binary distributables. I = probably should have noticed all that before uploading files, etc. Anyw= ay, I re-tagged and uploaded new tarballs/zip files, so all should be we= ll. -Mark |
|
From: Grzegorz L. <ha...@gm...> - 2005-08-19 21:46:39
|
I will try to sum up a little this discussion. Below are also solutions that where mentioned. * Is runtime jar needed? It can be useful. It will solve problems with conflicting libraries (e.g. bug report with ASM conflict) * Do _we_ really need runtime jar? Personally I don't need it. I really don't know how many people will actually need it. But it can be extremely helpful for people using different libraries versions (mainly ASM). * Should runtime jar be independent ? It is main goal of this library, but log4j dependency won't be probably too bad (from the other side without log4j library you could easily copy just single cobertura-runtime.jar to some location) * Do we need any logging system? Probably yes. It gives us possibility to turn on/off some logging. To be honest, I do not think it gives us anything more - it is just logging. Currently, we have about a hundred logging statements - some use log4j and some use System.out now. * Are we happy with log4j? In my opinion it is a very good tool - I use it in my work by default. It is well known tool, and probably good for Cobertura. The one place where it is risky to use log4j is at runtime, although the problems will be rare (as with nlog4j 1.2.15). Options: 1. Do nothing 2. Add cobertura-runtime.jar dependend only on log4j (no changes in code ne= eded) 3. Add independend cobertura-runtime.jar that doesn't log anything 4. Add independend cobertura-runtime.jar that uses System.out logging (rest of code use log4j) 5. Add independend cobertura-runtime.jar, add homegrown logging 5a. logging using java logging api or System.out if not found 5b. more sophisticated logging with some discovery process I would choose 5a or at least 4. Grzegorz FYI: I won't be working on Cobertura for next two weeks (maybe just a little on Eclipse plugin). On 8/19/05, Jeremy Thomerson <jer...@gm...> wrote: > I guess it all really comes down to this: > =20 > What are we trying to accomplish? > =20 > My understanding was that we had a two-fold purpose: > 1 - a single jar runtime (I don't think this is such a big deal, and don= 't > mind leaving log4j as a dependency) > 2 - support for < 1.4 (I think this is an absolute necessity, as we've s= een > when we first started and we were 1.4 dependent) > =20 > So, can we agree on what we should be trying to accomplish? What is the > demand for a single jar runtime? How many users want it? I don't think = it > has hurt our adoption rate to have a Log4J dependency. Honestly, I think > sticking with what we have is great until we have a good segment of users > that don't want Log4J in their instrumentation classpath. > =20 > Jeremy >=20 >=20 > On 8/19/05, Sinke, Mark (GE Healthcare) <mar...@me...> wrote: > >=20 > > Hi folks,=20 > > =20 > > Just to drop in my opinion: if we're trying to avoid shipping a JAR and= if > 1.4+ is not a problem, let's just go for using JDK logging. That avoids t= he > jar.=20 > > =20 > > If we want a really flexible logging library and do not mind the extra > jar, I'm ok with the current log4j solution.=20 > > =20 > > Let's in no case build our own wrapper or try to build a "simple" loggi= ng > system. We'll end up with code we don't want to maintain. And > System.out/.err is evil, but I don't need to tell you that, hopefully (at > least we want control over the levels of output). For the Ant task, we > should be redirecting the log4j output to the ant taskdef.=20 > > =20 > > My two cents,=20 > > =20 > > Mark.=20 > > =20 > > ________________________________ > =20 > > Mark J. Sinke > > Senior Software Architect/Lead System Designer Plasma 2.0 > (http://plasma.health.ge.com) > > GE Healthcare Information Technologies > > Core Infrastructure Platforms=20 > >=20 > > T +31 30 692 6000 > > F +31 30 692 6010 > > D *381 6446 > > E mar...@me...=20 > >=20 > > www.gehealthcare.com=20 > > =20 > >=20 > > ________________________________ > From: cob...@li... > [mailto:cob...@li...] On > Behalf Of Jeremy Thomerson > > Sent: Friday, August 19, 2005 05:19 > > To: Grzegorz Lukasik > > Cc: Seigel, James; Mark Doliner; > cob...@li... > >=20 > > Subject: Re: [Cobertura-devel] cobertura-runtime.jar? > >=20 > >=20 > >=20 > > My only question is this: Do you really think the majority of users us= e > JDK logging? I'd venture to say that the majority of our users use eithe= r a > home-grown logging solution, or one of the major ones available, like Log= 4J. > By the number of people that use Cobertura yet are not up to JRE / JDK 1= .4, > this would seem to be the case. But, I'm fine with going with a simple > solution if that's what everyone wants. I just think that if we build it > this way, it makes it really easy to add support for N different logging > systems, it shouldn't matter if we support 1 or 10. If we have the abili= ty > to dynamically determine if java.logging is on the class path, and if so, > use it, we can with minimum additional effort see if another one is > available. And users who don't use one that we create can create one cla= ss > to support their logging system. It's very plug-n-play. > >=20 > > JT > >=20 > >=20 > > On 8/18/05, Grzegorz Lukasik <ha...@gm...> wrote:=20 > > > Jeremy, > > >=20 > > > I suggest simplier version of your solution. Use just two loggers: > > > java logging api, and if cannot then use System.out/System.err. This > > > way majority of users will use JDK logging, and if someone needs to= =20 > > > use java version < 1.4 then raw output is provided. > > >=20 > > > Grzegorz > > >=20 > > > On 8/18/05, Jeremy Thomerson <jer...@gm...> wrote: > > > > This is actually along the lines of what I was thinking as well. I= f I > were=20 > > > > going to do it, here's what I would do: > > > > > > > > Create a class like James suggested that is always the class we go= to > to > > > > get a logger. > > > > The logger it returns is an interface (IBasicLogger?)=20 > > > > The factory class can check for several different common loggers, = in > the > > > > order that we prefer, and for each one you can have a class that wr= aps > the > > > > particular logger that it is designed to wrap with an implementatio= n > of our=20 > > > > basic interface. > > > > > > > > example: > > > > > > > > LoggingFactory: > > > > -- static method getLogger(String name) : returns IBasicLogger > > > > method basically goes through a list class names that we give it, = and > for=20 > > > > each one, knows which concrete class (see below) to instantiate. I= f > it > > > > finds no implemented logging classes on the classpath, falls back t= o > > > > SystemBasicLogger > > > > > > > > IBasicLogger: > > > > -- standard logging methods (debug, info, error, error with > Throwable)=20 > > > > Log4JBasicLogger: > > > > -- implements IBasicLogger. All calls to the interface methods g= et > > > > redirected to the Log4J logger that it contains (which is created u= pon > > > > construction, using the name that was passed to getLogger(String))= =20 > > > > SystemBasicLogger : implements IBasicLogger, formats and sends > messages to > > > > System.out, System.err, as appropriate > > > > <OtherLogger>BasicLogger : same as Log4J implementation, but > redirects to > > > > whatever logging facility it is designed to wrap. > > > > > > > > I'd love to work on this for the next release (not 1.6 on Monday) = if > > > > everyone likes it. > > > > > > > > Jeremy > > > > > > > > > > > > On 8/18/05, Seigel, James < Jam...@av...> wrote: > > > > > > > > > > Wrap log4j and make a factory method that determines if it is > there... > > > > > > > > > > public class Clogger {=20 > > > > > private static Clogger logger =3D null; > > > > > > > > > > public static Clogger getLogger() { > > > > > if(logger =3D=3D null) { > > > > > logger =3D determineLogger(); > > > > > }=20 > > > > > return logger; > > > > > } > > > > > > > > > > private static Clogger determineLogger() { > > > > > // class load log4j logger if fails > > > > > // return Clogger instance of system.out.println > > > > > // else return a "wrapped" log4j logger with forwarding > methods > > > > > } > > > > > > > > > > . > > > > > . > > > > > . > > > > > > > > > > }=20 > > > > > > > > > > Just as an idea.....but I am on holiday..brain broken > > > > > > > > > > Cheers > > > > > James. > > > > > > > > > > -----Original Message----- > > > > > From: cob...@li...=20 > > > > > [mailto: > cob...@li...] On > > > > Behalf Of > > > > > Grzegorz Lukasik=20 > > > > > Sent: Thursday, August 18, 2005 1:33 PM > > > > > To: Mark Doliner > > > > > Cc: cob...@li... > > > > > Subject: Re: [Cobertura-devel] cobertura-runtime.jar? > > > > > > > > > > Here are two additional articles about JCL written by the author = of > > > > > log4j. The conclusion of both is the same - JCL can produce > unexpected > > > > > problems with its "dynamic discovery mechanism".=20 > > > > > > > > > > Think again before adopting the commons-logging API > > > > > http://www.qos.ch/logging/thinkAgain.jsp > > > > > > > > > > Taxonomy of class loader problems encountered when using Jakarta > Commons=20 > > > > > Logging > > > > > http://www.qos.ch/logging/classloader.jsp=20 > > > > > > > > > > > > > > > Mentioned is also Simple Logging Facade for Java (SLF4J) as a=20 > > > > > replacement for JCL. The problem with all this solutions is that = we > > > > > would need concrete implementation of some logger included. > > > > > > > > > > Alternatively, we could use java logging api, but then Cobertura > would=20 > > > > > not work with JDK<1.4 (what is not so bad afterall). > > > > > > > > > > I think that the easiest solution would be just to create our own > > > > > logging "system" (I will try to create it), so that we do not hav= e > to=20 > > > > > bother. > > > > > > > > > > Don't hesitate to send your comments. > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > On 8/18/05, Mark Doliner < Mar...@sa...> wrote: > > > > > > After reading that article, I kind of like Jakarta Commons > Logging. > > > > > It sounds like it would be small, not cause many conflicts, and f= or > most > > > > > people it would just use the logging built into JDK 1.4 and highe= r.=20 > It > > > > > sounds like it's basically a simple logging class written by the > Jakarta > > > > > people. > > > > > > -Mark > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: > cob...@li...=20 > > > > > > > [mailto: > cob...@li...] > > > > On > > > > > > > Behalf Of Grzegorz Lukasik > > > > > > > Sent: Thursday, August 18, 2005 7:35 AM > > > > > > > To: Mark Doliner > > > > > > > Cc: cob...@li... > > > > > > > Subject: Re: [Cobertura-devel] cobertura-runtime.jar? > > > > > > > > > > > > > > My vote goes to simple logging class.=20 > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > On 8/18/05, Grzegorz Lukasik <ha...@gm... > wrote: > > > > > > > > I have checked some other tools (not too many as you can se= e): > > > > > > > > > > > > > > > > EMMA: homegrown logging utility > > > > > > > > Clover: in library they have org.apache.log subdirectory, > > > > > > > so maybe log4j is used > > > > > > > > NoUnit: Log4j > > > > > > > > Spring: Jakarta Commons Logging > > > > > > > > Tomcat: Jakarta Commons Logging > > > > > > > > > > > > > > > > BTW. Interesting note created by JCL author:=20 > > > > > > > > > http://radio.weblogs.com/0122027/2003/08/15.html=20 > > > > > > > > > > > > > > > > Grzegorz > > > > > > > >=20 > > > > > > > > > > > > > > > > On 8/18/05, Grzegorz Lukasik < ha...@gm...> wrote: > > > > > > > > > The one option that I like in log4j configuration now, is > the=20 > > > > > > > > > possibility to turn more verbose level on. As you wrote, > > > > > > > if we will > > > > > > > > > use plain System.out/System.err solution we will have to > > > > > > > remove a lot=20 > > > > > > > > > of current output messages. > > > > > > > > > > > > > > > > > > Maybe we could use some very lighweight logger (single cl= ass > > > > > with > > > > > > > > > debug, info, error methods).=20 > > > > > > > > > > > > > > > > > > I will check other tools, to check how they handle it. > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > >=20 > > > > > > > > > On 8/17/05, Mark Doliner <ma...@ki...> wrote: > > > > > > > > > > Eh, I guess I don't have a strong opinion either way. > > > > > > > What do you think about > > > > > > > > > > maybe removing a lot of our current log4j output, and > > > > > > > changing the rest to > > > > > > > > > > System.out or System.err, and getting rid of log4j > entirely? > > > > > > > > > > > > > > > > > > > > -Mark > > > > > > > > > > > > > > > > > > > > On Tue, 16 Aug 2005 19:52:49 +0200, Grzegorz Lukasik wr= ote > > > > > > > > > > > I have created quick patch that replaces log4j calls > > > > > > > in coveragedata > > > > > > > > > > > package with System.out/System.err. > > > > > > > > > > > cobertura-runtime.jar is now created. It contains > classes > > > > > from > > > > > > > > > > > coveragedata package and > > > > > > > > > > > all referenced. It does not depend on any libraries.= =20 > > > > > > > > > > > > > > > > > > > > > > I am not sure if it is a good solution. Any opinions? > > > > > > > > > > > > > > > > > > > > > > I have removed classpath entries in javac task that= =20 > > > > > > > point to the > > > > > > > > > > > directory where class files > > > > > > > > > > > are copied - does it make any sense? > > > > > > > > > > >=20 > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > On 8/16/05, Grzegorz Lukasik <ha...@gm... > wro= te: > > > > > > > > > > > > There is related RFE - > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1255 > > > > > > > 210&group_id=3D130558&atid=3D720018 > > > > > > > > > > > > > > > > > > > > > > > > Maybe we could create cobertura.jar as normal, and > > > > > > > additionaly create > > > > > > > > > > > > cobertura-runtime.jar that can be optionally used. > > > > > > > Not so nice > > > > > > > > > > > > solution, but=20 > > > > > > > > > > > > users would be able to upgrade without problems. > > > > > > > > > > > > > > > > > > > > > > > > cobertura-runtime.jar should not contain any=20 > > > > > > > references to dependend > > > > > > > > > > > > libraries - we could replace log4j with System.out, > > > > > > > System.err for > > > > > > > > > > > > coveragedata package (grrrrrr...).=20 > > > > > > > > > > > > > > > > > > > > > > > > Grzegorz > > > > > > > > > > > > > > > > > > > > > > > > On 6/17/05, Seigel, James < Jam...@av...= m > > > > > > wrote: > > > > > > > > > > > > > I like having the one jar. I will have to have > > > > > > > both around anyway. No=20 > > > > > > > > > > > > > opinion on naming scheme. > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > > > > James.=20 > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: > > > > cob...@li...=20 > > > > > > > > > > > > > > > > > > > > [mailto: > cob...@li... ] > > > > On Behalf Of > > > > > Mark > > > > > > > > > > > > > Doliner > > > > > > > > > > > > > Sent: Thursday, June 16, 2005 2:33 PM > > > > > > > > > > > > > To: > cob...@li... > > > > > > > > > > > > > Subject: [Cobertura-devel] cobertura-runtime.jar? > > > > > > > > > > > > >=20 > > > > > > > > > > > > > Cobertura currently consists of one jar file, and > > > > > > > this jar must be on > > > > > > > > > > > > > your classpath when instrumenting, running tests,= =20 > > > > > > > and reporting. > > > > > > > > > > > > > However, when you actually run your tests, only > > > > > > > one of the packages in > > > > > > > > > > > > > this jar is used, and the package only requires > log4j.=20 > > > > > > > > > > > > > > > > > > > > > > > > > > How do people feel about creating a cobertura.jar > and a > > > > > > > > > > > > > cobertura-runtime.jar , where > > > > > > > cobertura-runtime.jar contains all the > > > > > > > > > > > > > classes in the package > > > > > > > net.sourceforge.cobertura.coveragedata. And > > > > > > > > > > > > > cobertura.jar would contain everything else (ant > > > > > > > tasks, instrumenting > > > > > > > > > > > > > code, reporting code, etc.) > > > > > > > > > > > > >=20 > > > > > > > > > > > > > The goal is to make it more clear that asm, ncss, > > > > > > > jakarta-oro, etc. are > > > > > > > > > > > > > not required when running instrumenting code. I= =20 > > > > > > > think this would help > > > > > > > > > > > > > avoid classpath conflicts with ASM. > > > > > > > > > > > > > > > > > > > > > > > > > > Good idea? Bad idea? Suggestions for better=20 > > > > > > > names for the jars? > > > > > > > > > > > > > Should the jars include the version number in the= ir > name > > > > > > > > > > > > > ("cobertura-1.5.jar ")? Should the runtime jar > > > > > > > still use log4j, or > > > > > > > > > > > > > should we get rid of that dependency? > > > > > > > > > > > > > > > > > > > > > > > > > > FYI, I'll be out of town from now until Sunday > night. > > > > > > > > > > > > > > > > > > > > > > > > > > -Mark > > > > > > > > > >=20 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------=20 > > > > > > > SF.Net email is Sponsored by the Better Software Conference & > EXPO > > > > > > > September 19-22, 2005 * San Francisco, CA * Development > > > > > > > Lifecycle Practices > > > > > > > Agile & Plan-Driven Development * Managing Projects & Teams *= =20 > > > > > > > Testing & QA > > > > > > > Security * Process Improvement & Measurement * > > > > > > > http://www.sqe.com/bsce5sf > > > > > > > _______________________________________________ > > > > > > > Cobertura-devel mailing list > > > > > > > Cob...@li...=20 > > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > SF.Net email is Sponsored by the Better Software Conference & E= XPO > > > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecyc= le > > > > > Practices > > > > > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing=20 > > > > > & QA > > > > > > Security * Process Improvement & Measurement * > > > > > http://www.sqe.com/bsce5sf > > > > > > _______________________________________________=20 > > > > > > Cobertura-devel mailing list > > > > > > Cob...@li... > > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > SF.Net email is Sponsored by the Better Software Conference & EXP= O=20 > > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > > > > > Practices > > > > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & > > > > > QA > > > > > Security * Process Improvement & Measurement *=20 > > > > > http://www.sqe.com/bsce5sf > > > > > _______________________________________________ > > > > > Cobertura-devel mailing list > > > > > Cob...@li... > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > > >=20 > > > > > > ------------------------------------------------------- > > > > > SF.Net email is Sponsored by the Better Software Conference & EXP= O > > > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle= =20 > > > > Practices > > > > > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > > > > > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf=20 > > > > > _______________________________________________ > > > > > Cobertura-devel mailing list > > > > > Cob...@li... > > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/cobertura-devel > > > > > > > > > > > > > > > > > > > > > > > > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 > |
|
From: Jared R. <Jar...@sa...> - 2005-08-19 13:52:51
|
Remember that Log4J has intentionally broken their backwards compatibili= ty in the past. Having a thin wrapper around any logging mechanism (or a= ny "third party" code) is usually a good idea. It buys you a lot of flex= ibility and removes your dependence on a single toolkit. Jared http://www.jaredrichardson.net ________________________________ =09From: cob...@li... [mailto:cobertura-d= eve...@li...] On Behalf Of Sinke, Mark (GE Healthcar= e) =09Sent: Friday, August 19, 2005 7:08 AM =09To: je...@th...; Grzegorz Lukasik =09Cc: Seigel, James; Mark Doliner; cob...@li...= t =09Subject: RE: [Cobertura-devel] cobertura-runtime.jar? =09 =09 =09Hi folks, =09 =09Just to drop in my opinion: if we're trying to avoid shipping a JAR a= nd if 1.4+ is not a problem, let's just go for using JDK logging. That a= voids the jar. =09 =09If we want a really flexible logging library and do not mind the extr= a jar, I'm ok with the current log4j solution. =09 =09Let's in no case build our own wrapper or try to build a "simple" log= ging system. We'll end up with code we don't want to maintain. And Syste= m.out/.err is evil, but I don't need to tell you that, hopefully (at lea= st we want control over the levels of output). For the Ant task, we shou= ld be redirecting the log4j output to the ant taskdef. =09 =09My two cents, =09 =09Mark. =09 ________________________________ =09Mark J. Sinke =09Senior Software Architect/Lead System Designer Plasma 2.0 (http://pla= sma.health.ge.com <http://plasma.health.ge.com/> ) =09GE Healthcare Information Technologies =09Core Infrastructure Platforms =09T +31 30 692 6000 =09F +31 30 692 6010 =09D *381 6446 =09E mar...@me... <mailto:mar...@me...> =09www.gehealthcare.com <http://www.gehealthcare.com/> =09 ________________________________ =09From: cob...@li... [mailto:cobertura-d= eve...@li...] On Behalf Of Jeremy Thomerson =09Sent: Friday, August 19, 2005 05:19 =09To: Grzegorz Lukasik =09Cc: Seigel, James; Mark Doliner; cob...@li...= t =09Subject: Re: [Cobertura-devel] cobertura-runtime.jar? =09 =09 =09My only question is this: Do you really think the majority of users = use JDK logging? I'd venture to say that the majority of our users use = either a home-grown logging solution, or one of the major ones available= , like Log4J. By the number of people that use Cobertura yet are not up= to JRE / JDK 1.4, this would seem to be the case. But, I'm fine with g= oing with a simple solution if that's what everyone wants. I just think= that if we build it this way, it makes it really easy to add support fo= r N different logging systems, it shouldn't matter if we support 1 or 10= . If we have the ability to dynamically determine if java.logging is on= the class path, and if so, use it, we can with minimum additional effor= t see if another one is available. And users who don't use one that we = create can create one class to support their logging system. It's very p= lug-n-play. =09 =09JT =09 =09 =09On 8/18/05, Grzegorz Lukasik <ha...@gm...> wrote: =09=09Jeremy, =09=09 =09=09I suggest simplier version of your solution. Use just two loggers: =09=09java logging api, and if cannot then use System.out/System.err. Th= is =09=09way majority of users will use JDK logging, and if someone needs t= o =09=09use java version < 1.4 then raw output is provided. =09=09 =09=09Grzegorz =09=09 =09=09On 8/18/05, Jeremy Thomerson <jer...@gm...> wrote: =09=09> This is actually along the lines of what I was thinking as well.= If I were =09=09> going to do it, here's what I would do: =09=09> =09=09> Create a class like James suggested that is always the class we= go to to =09=09> get a logger. =09=09> The logger it returns is an interface (IBasicLogger?) =09=09> The factory class can check for several different common logger= s, in the =09=09> order that we prefer, and for each one you can have a class that= wraps the =09=09> particular logger that it is designed to wrap with an implementa= tion of our =09=09> basic interface. =09=09> =09=09> example: =09=09> =09=09> LoggingFactory: =09=09> -- static method getLogger(String name) : returns IBasicLogger =09=09> method basically goes through a list class names that we give i= t, and for =09=09> each one, knows which concrete class (see below) to instantiate.= If it =09=09> finds no implemented logging classes on the classpath, falls bac= k to =09=09> SystemBasicLogger =09=09> =09=09> IBasicLogger: =09=09> -- standard logging methods (debug, info, error, error with Th= rowable) =09=09> Log4JBasicLogger: =09=09> -- implements IBasicLogger. All calls to the interface method= s get =09=09> redirected to the Log4J logger that it contains (which is create= d upon =09=09> construction, using the name that was passed to getLogger(String= )) =09=09> SystemBasicLogger : implements IBasicLogger, formats and sends = messages to =09=09> System.out, System.err, as appropriate =09=09> <OtherLogger>BasicLogger : same as Log4J implementation, but re= directs to =09=09> whatever logging facility it is designed to wrap. =09=09> =09=09> I'd love to work on this for the next release (not 1.6 on Monda= y) if =09=09> everyone likes it. =09=09> =09=09> Jeremy =09=09> =09=09> =09=09> On 8/18/05, Seigel, James < Jam...@av...> wrote: =09=09> > =09=09> > Wrap log4j and make a factory method that determines if it is = there... =09=09> > =09=09> > public class Clogger { =09=09> > private static Clogger logger =3D null; =09=09> > =09=09> > public static Clogger getLogger() { =09=09> > if(logger =3D=3D null) { =09=09> > logger =3D determineLogger(); =09=09> > } =09=09> > return logger; =09=09> > } =09=09> > =09=09> > private static Clogger determineLogger() { =09=09> > // class load log4j logger if fails =09=09> > // return Clogger instance of system.out.println =09=09> > // else return a "wrapped" log4j logger with forwardin= g methods =09=09> > } =09=09> > =09=09> > . =09=09> > . =09=09> > . =09=09> > =09=09> > } =09=09> > =09=09> > Just as an idea.....but I am on holiday..brain broken =09=09> > =09=09> > Cheers =09=09> > James. =09=09> > =09=09> > -----Original Message----- =09=09> > From: cob...@li... =09=09> > [mailto: cob...@li...] On =09=09> Behalf Of =09=09> > Grzegorz Lukasik =09=09> > Sent: Thursday, August 18, 2005 1:33 PM =09=09> > To: Mark Doliner =09=09> > Cc: cob...@li... =09=09> > Subject: Re: [Cobertura-devel] cobertura-runtime.jar? =09=09> > =09=09> > Here are two additional articles about JCL written by the auth= or of =09=09> > log4j. The conclusion of both is the same - JCL can produce un= expected =09=09> > problems with its "dynamic discovery mechanism". =09=09> > =09=09> > Think again before adopting the commons-logging API =09=09> > http://www.qos.ch/logging/thinkAgain.jsp =09=09> > =09=09> > Taxonomy of class loader problems encountered when using Jakar= ta Commons =09=09> > Logging =09=09> > http://www.qos.ch/logging/classloader.jsp =09=09> > =09=09> > =09=09> > Mentioned is also Simple Logging Facade for Java (SLF4J) as a =09=09> > replacement for JCL. The problem with all this solutions is th= at we =09=09> > would need concrete implementation of some logger included. =09=09> > =09=09> > Alternatively, we could use java logging api, but then Cobertu= ra would =09=09> > not work with JDK<1.4 (what is not so bad afterall). =09=09> > =09=09> > I think that the easiest solution would be just to create our = own =09=09> > logging "system" (I will try to create it), so that we do not = have to =09=09> > bother. =09=09> > =09=09> > Don't hesitate to send your comments. =09=09> > =09=09> > =09=09> > Grzegorz =09=09> > =09=09> > On 8/18/05, Mark Doliner < Mar...@sa...> wrote: =09=09> > > After reading that article, I kind of like Jakarta Commons L= ogging. =09=09> > It sounds like it would be small, not cause many conflicts, an= d for most =09=09> > people it would just use the logging built into JDK 1.4 and hi= gher. It =09=09> > sounds like it's basically a simple logging class written by t= he Jakarta =09=09> > people. =09=09> > > -Mark =09=09> > > =09=09> > > > -----Original Message----- =09=09> > > > From: cob...@li... =09=09> > > > [mailto: cob...@li... <mail= to:cob...@li...> ] =09=09> On =09=09> > > > Behalf Of Grzegorz Lukasik =09=09> > > > Sent: Thursday, August 18, 2005 7:35 AM =09=09> > > > To: Mark Doliner =09=09> > > > Cc: cob...@li... =09=09> > > > Subject: Re: [Cobertura-devel] cobertura-runtime.jar? =09=09> > > > =09=09> > > > My vote goes to simple logging class. =09=09> > > > =09=09> > > > Grzegorz =09=09> > > > =09=09> > > > On 8/18/05, Grzegorz Lukasik <ha...@gm... > wrote: =09=09> > > > > I have checked some other tools (not too many as you can= see): =09=09> > > > > =09=09> > > > > EMMA: homegrown logging utility =09=09> > > > > Clover: in library they have org.apache.log subdirectory= , =09=09> > > > so maybe log4j is used =09=09> > > > > NoUnit: Log4j =09=09> > > > > Spring: Jakarta Commons Logging =09=09> > > > > Tomcat: Jakarta Commons Logging =09=09> > > > > =09=09> > > > > BTW. Interesting note created by JCL author: =09=09> > > > > http://radio.weblogs.com/0122027/2003/08/15.html =09=09> > > > > =09=09> > > > > Grzegorz =09=09> > > > > =09=09> > > > > =09=09> > > > > On 8/18/05, Grzegorz Lukasik < ha...@gm...> wrote: =09=09> > > > > > The one option that I like in log4j configuration now,= is the =09=09> > > > > > possibility to turn more verbose level on. As you wrot= e, =09=09> > > > if we will =09=09> > > > > > use plain System.out/System.err solution we will have = to =09=09> > > > remove a lot =09=09> > > > > > of current output messages. =09=09> > > > > > =09=09> > > > > > Maybe we could use some very lighweight logger (single= class =09=09> > with =09=09> > > > > > debug, info, error methods). =09=09> > > > > > =09=09> > > > > > I will check other tools, to check how they handle it. =09=09> > > > > > =09=09> > > > > > Grzegorz =09=09> > > > > > =09=09> > > > > > On 8/17/05, Mark Doliner <ma...@ki...> wrote: =09=09> > > > > > > Eh, I guess I don't have a strong opinion either way= . =09=09> > > > What do you think about =09=09> > > > > > > maybe removing a lot of our current log4j output, an= d =09=09> > > > changing the rest to =09=09> > > > > > > System.out or System.err, and getting rid of log4j e= ntirely? =09=09> > > > > > > =09=09> > > > > > > -Mark =09=09> > > > > > > =09=09> > > > > > > On Tue, 16 Aug 2005 19:52:49 +0200, Grzegorz Lukasik= wrote =09=09> > > > > > > > I have created quick patch that replaces log4j cal= ls =09=09> > > > in coveragedata =09=09> > > > > > > > package with System.out/System.err. =09=09> > > > > > > > cobertura-runtime.jar is now created. It contains = classes =09=09> > from =09=09> > > > > > > > coveragedata package and =09=09> > > > > > > > all referenced. It does not depend on any librarie= s. =09=09> > > > > > > > =09=09> > > > > > > > I am not sure if it is a good solution. Any opinio= ns? =09=09> > > > > > > > =09=09> > > > > > > > I have removed classpath entries in javac task tha= t =09=09> > > > point to the =09=09> > > > > > > > directory where class files =09=09> > > > > > > > are copied - does it make any sense? =09=09> > > > > > > > =09=09> > > > > > > > Grzegorz =09=09> > > > > > > > =09=09> > > > > > > > On 8/16/05, Grzegorz Lukasik <ha...@gm... > = wrote: =09=09> > > > > > > > > There is related RFE - =09=09> > > > > > > > > =09=09> > > > > > > =09=09> > > > =09=09> https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D12= 55 =09=09> > > > 210&group_id=3D130558&atid=3D720018 =09=09> > > > > > > > > =09=09> > > > > > > > > Maybe we could create cobertura.jar as normal, a= nd =09=09> > > > additionaly create =09=09> > > > > > > > > cobertura-runtime.jar that can be optionally use= d. =09=09> > > > Not so nice =09=09> > > > > > > > > solution, but =09=09> > > > > > > > > users would be able to upgrade without problems. =09=09> > > > > > > > > =09=09> > > > > > > > > cobertura-runtime.jar should not contain any =09=09> > > > references to dependend =09=09> > > > > > > > > libraries - we could replace log4j with System.o= ut, =09=09> > > > System.err for =09=09> > > > > > > > > coveragedata package (grrrrrr...). =09=09> > > > > > > > > =09=09> > > > > > > > > Grzegorz =09=09> > > > > > > > > =09=09> > > > > > > > > On 6/17/05, Seigel, James < James.Seigel@avocent= .com > =09=09> > wrote: =09=09> > > > > > > > > > I like having the one jar. I will have to hav= e =09=09> > > > both around anyway. No =09=09> > > > > > > > > > opinion on naming scheme. =09=09> > > > > > > > > > =09=09> > > > > > > > > > Cheers =09=09> > > > > > > > > > James. =09=09> > > > > > > > > > =09=09> > > > > > > > > > -----Original Message----- =09=09> > > > > > > > > > From: =09=09> cob...@li... =09=09> > > > > > > > > > =09=09> > > > [mailto: cob...@li... ] =09=09> On Behalf Of =09=09> > Mark =09=09> > > > > > > > > > Doliner =09=09> > > > > > > > > > Sent: Thursday, June 16, 2005 2:33 PM =09=09> > > > > > > > > > To: cob...@li... =09=09> > > > > > > > > > Subject: [Cobertura-devel] cobertura-runtime.j= ar? =09=09> > > > > > > > > > =09=09> > > > > > > > > > Cobertura currently consists of one jar file, = and =09=09> > > > this jar must be on =09=09> > > > > > > > > > your classpath when instrumenting, running tes= ts, =09=09> > > > and reporting. =09=09> > > > > > > > > > However, when you actually run your tests, onl= y =09=09> > > > one of the packages in =09=09> > > > > > > > > > this jar is used, and the package only require= s log4j. =09=09> > > > > > > > > > =09=09> > > > > > > > > > How do people feel about creating a cobertura.= jar and a =09=09> > > > > > > > > > cobertura-runtime.jar , where =09=09> > > > cobertura-runtime.jar contains all the =09=09> > > > > > > > > > classes in the package =09=09> > > > net.sourceforge.cobertura.coveragedata. And =09=09> > > > > > > > > > cobertura.jar would contain everything else (a= nt =09=09> > > > tasks, instrumenting =09=09> > > > > > > > > > code, reporting code, etc.) =09=09> > > > > > > > > > =09=09> > > > > > > > > > The goal is to make it more clear that asm, nc= ss, =09=09> > > > jakarta-oro, etc. are =09=09> > > > > > > > > > not required when running instrumenting code. = I =09=09> > > > think this would help =09=09> > > > > > > > > > avoid classpath conflicts with ASM. =09=09> > > > > > > > > > =09=09> > > > > > > > > > Good idea? Bad idea? Suggestions for better =09=09> > > > names for the jars? =09=09> > > > > > > > > > Should the jars include the version number in = their name =09=09> > > > > > > > > > ("cobertura-1.5.jar ")? Should the runtime ja= r =09=09> > > > still use log4j, or =09=09> > > > > > > > > > should we get rid of that dependency? =09=09> > > > > > > > > > =09=09> > > > > > > > > > FYI, I'll be out of town from now until Sunday= night. =09=09> > > > > > > > > > =09=09> > > > > > > > > > -Mark =09=09> > > > > > > =09=09> > > > > > > =09=09> > > > > > =09=09> > > > > =09=09> > > > =09=09> > > > =09=09> > > > =09=09> ------------------------------------------------------- =09=09> > > > SF.Net email is Sponsored by the Better Software Conferenc= e & EXPO =09=09> > > > September 19-22, 2005 * San Francisco, CA * Development =09=09> > > > Lifecycle Practices =09=09> > > > Agile & Plan-Driven Development * Managing Projects & Team= s * =09=09> > > > Testing & QA =09=09> > > > Security * Process Improvement & Measurement * =09=09> > > > http://www.sqe.com/bsce5sf =09=09> > > > _______________________________________________ =09=09> > > > Cobertura-devel mailing list =09=09> > > > Cob...@li... =09=09> > > > =09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel =09=09> > > > =09=09> > > =09=09> > > =09=09> > > ------------------------------------------------------- =09=09> > > SF.Net email is Sponsored by the Better Software Conference = & EXPO =09=09> > > September 19-22, 2005 * San Francisco, CA * Development Life= cycle =09=09> > Practices =09=09> > > Agile & Plan-Driven Development * Managing Projects & Teams = * Testing =09=09> > & QA =09=09> > > Security * Process Improvement & Measurement * =09=09> > http://www.sqe.com/bsce5sf =09=09> > > _______________________________________________ =09=09> > > Cobertura-devel mailing list =09=09> > > Cob...@li... =09=09> > > =09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel =09=09> > > =09=09> > =09=09> > =09=09> > ------------------------------------------------------- =09=09> > SF.Net email is Sponsored by the Better Software Conference & = EXPO =09=09> > September 19-22, 2005 * San Francisco, CA * Development Lifecy= cle =09=09> > Practices =09=09> > Agile & Plan-Driven Development * Managing Projects & Teams * = Testing & =09=09> > QA =09=09> > Security * Process Improvement & Measurement * =09=09> > http://www.sqe.com/bsce5sf =09=09> > _______________________________________________ =09=09> > Cobertura-devel mailing list =09=09> > Cob...@li... =09=09> > =09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel =09=09> > =09=09> > =09=09> > ------------------------------------------------------- =09=09> > SF.Net email is Sponsored by the Better Software Conference & = EXPO =09=09> > September 19-22, 2005 * San Francisco, CA * Development Lifecy= cle =09=09> Practices =09=09> > Agile & Plan-Driven Development * Managing Projects & Teams * = Testing & QA =09=09> > Security * Process Improvement & Measurement * http://www.sqe.= com/bsce5sf =09=09> > _______________________________________________ =09=09> > Cobertura-devel mailing list =09=09> > Cob...@li... =09=09> > =09=09> https://lists.sourceforge.net/lists/listinfo/cobertura-devel =09=09> > =09=09> > =09=09> > =09=09> =09=09> =09=09 =09=09 =09=09 |
89 messages has been excluded from this view by a project administrator.
