cobertura-devel — General questions about using and developing Cobertura.

[Cobertura-devel] Coverage with Cobertura

[aaditya p. <pva...@gm...>]

Hi,

Is there a way to exclude some classes from the coverage report using
cobertura-jenkins plugin for a maven project?

thanks,
aaditya.

Re: [Cobertura-devel] war file creation in maven for cobertura instrumented classes

[Steve C. <sch...@gm...>]

You might want to report this the cobertura maven plugin mailing list:
http://mojo.codehaus.org/cobertura-maven-plugin/mail-lists.html.


On Fri, Feb 1, 2013 at 7:38 PM, Rajagopal, Sampath <
Sam...@vc...> wrote:

>   I have cobertura:instrument goal working in my environment. The
> instrumented classes are created in generated-classes/cobertura dir while
> the conventional classes are created in target/classes dir. I believe this
> is as it should.
>
> Currently it creates a war out of target/classes dir. I would also like to
> be able to create a war out of classes/cobertura. Would someone suggest a
> POM example, to achieve this ? Thanks
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>

[Cobertura-devel] war file creation in maven for cobertura instrumented classes

[Rajagopal, S. <Sam...@vc...>]

I have cobertura:instrument goal working in my environment. The instrumented classes are created in generated-classes/cobertura dir while the conventional classes are created in target/classes dir. I believe this is as it should.

Currently it creates a war out of target/classes dir. I would also like to be able to create a war out of classes/cobertura. Would someone suggest a POM example, to achieve this ? Thanks

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Ravishankar, C. <Cha...@nd...>]

Hi Steve,

The cobertura 1.9.4.1 uses Generics, annotations etc.. , the features available from 1.5.

How it will be possible to compile them using 1.4?

Did you try by changing the javac.target to 1.4 in the build.properties?

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...]
Sent: Monday, January 21, 2013 11:58 AM
To: Ravishankar, Chandan
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

An issue I forgot to mention was I got a compilation error "unable to locate the java compiler com.sun.tools.javac.Main, please change your classloader settings". To resolve this you can't compile cobertura using openjdk, but instead using the sun/oracle jdk because it's looking for the lib/tools.jar folder from your $JAVA_HOME/jre directory.

On Mon, Jan 21, 2013 at 12:25 AM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Oh OK.

Let me give a try.

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...<mailto:sch...@gm...>]
Sent: Monday, January 21, 2013 11:53 AM

To: Ravishankar, Chandan
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

I was actually able to compile the latest version of cobertura using javac 1.4 as an argument. I just checked out the latest version of the source code: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/ and opened the build.xml file, changed all the javac1.5 versions to 1.4, ran the default ant target and had no compilation issues.

On Sun, Jan 20, 2013 at 11:47 PM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Hi Steve,

Thanks for the reply. Unfortunately that is not possible.

To work on Java 5 we need to port new JVM to our device and it won't be possible as we have many constraints :(.

So the only option for me is to use 1.9 with Java 1.4.

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...<mailto:sch...@gm...>]
Sent: Monday, January 21, 2013 11:15 AM
To: Ravishankar, Chandan
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe still has support for java 5 according to the ChangeLog and Bug 2962599.

On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Hi All,

Please let me know if you think it is worth to invest time in this area or if any other alternatives.

Regards,
Chandan

From: Ravishankar, Chandan
Sent: Thursday, January 17, 2013 6:33 PM
To: 'cob...@li...<mailto:cob...@li...>'
Subject: Cobertura 1.9 performance improvements

Hi All,

I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.

The software becomes slow when I run with the instrumented classes.

I wanted to see if I can optimize cobertura and still use it on Java 1.4.

I see in the latest versions we use concurrent collections instead of synchronized ones.

Any other good starting points?

Regards,
Chandan Ravishankar | Desk: 64529 | Cell: +91 994 550 1674<tel:%2B91%20994%20550%201674>


________________________________

This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the pos...@nd...<mailto:pos...@nd...> and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com<http://www.nds.com>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Steve C. <sch...@gm...>]

An issue I forgot to mention was I got a compilation error "unable to
locate the java compiler com.sun.tools.javac.Main, please change your
classloader settings". To resolve this you can't compile cobertura using
openjdk, but instead using the sun/oracle jdk because it's looking for the
lib/tools.jar folder from your $JAVA_HOME/jre directory.


On Mon, Jan 21, 2013 at 12:25 AM, Ravishankar, Chandan <Cha...@nd...>wrote:

>  Oh OK.****
>
> ** **
>
> Let me give a try.****
>
> ** **
>
> Regards,****
>
> Chandan****
>
> ** **
>
> *From:* Steve Christou [mailto:sch...@gm...]
> *Sent:* Monday, January 21, 2013 11:53 AM
>
> *To:* Ravishankar, Chandan
> *Cc:* cob...@li...
> *Subject:* Re: [Cobertura-devel] Cobertura 1.9 performance improvements***
> *
>
>  ** **
>
> I was actually able to compile the latest version of cobertura using javac
> 1.4 as an argument. I just checked out the latest version of the source
> code:
> http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/ and
> opened the build.xml file, changed all the javac1.5 versions to 1.4, ran
> the default ant target and had no compilation issues.****
>
> ** **
>
> On Sun, Jan 20, 2013 at 11:47 PM, Ravishankar, Chandan <Cha...@nd...>
> wrote:****
>
> Hi Steve,****
>
>  ****
>
> Thanks for the reply. Unfortunately that is not possible.****
>
>  ****
>
> To work on Java 5 we need to port new JVM to our device and it won’t be
> possible as we have many constraints L.****
>
>  ****
>
> So the only option for me is to use 1.9 with Java 1.4.****
>
>  ****
>
> Regards,****
>
> Chandan****
>
>  ****
>
> *From:* Steve Christou [mailto:sch...@gm...]
> *Sent:* Monday, January 21, 2013 11:15 AM
> *To:* Ravishankar, Chandan
> *Cc:* cob...@li...
> *Subject:* Re: [Cobertura-devel] Cobertura 1.9 performance improvements***
> *
>
>  ****
>
> Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe
> still has support for java 5 according to the ChangeLog and Bug 2962599.**
> **
>
>  ****
>
> On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...>
> wrote:****
>
> Hi All,****
>
>  ****
>
> Please let me know if you think it is worth to invest time in this area or
> if any other alternatives.****
>
>  ****
>
> Regards,****
>
> Chandan****
>
>  ****
>
> *From:* Ravishankar, Chandan
> *Sent:* Thursday, January 17, 2013 6:33 PM
> *To:* 'cob...@li...'
> *Subject:* Cobertura 1.9 performance improvements****
>
>  ****
>
> Hi All,****
>
>  ****
>
> I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.****
>
>  ****
>
> The software becomes slow when I run with the instrumented classes.****
>
>  ****
>
> I wanted to see if I can optimize cobertura and still use it on Java 1.4.*
> ***
>
>  ****
>
> I see in the latest versions we use concurrent collections instead of
> synchronized ones.****
>
>  ****
>
> Any other good starting points? ****
>
>  ****
>
> Regards,****
>
> *Chandan Ravishankar* | Desk: 64529 | Cell: +91 994 550 1674****
>
>  ****
>
>  ****
>  ------------------------------
>
>
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> pos...@nd... and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes.
> To protect the environment please do not print this e-mail unless
> necessary.
>
> An NDS Group Limited company. www.nds.com****
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel****
>
>  ****
>
> ** **
>

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Ravishankar, C. <Cha...@nd...>]

Oh OK.

Let me give a try.

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...]
Sent: Monday, January 21, 2013 11:53 AM
To: Ravishankar, Chandan
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

I was actually able to compile the latest version of cobertura using javac 1.4 as an argument. I just checked out the latest version of the source code: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/ and opened the build.xml file, changed all the javac1.5 versions to 1.4, ran the default ant target and had no compilation issues.

On Sun, Jan 20, 2013 at 11:47 PM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Hi Steve,

Thanks for the reply. Unfortunately that is not possible.

To work on Java 5 we need to port new JVM to our device and it won't be possible as we have many constraints :(.

So the only option for me is to use 1.9 with Java 1.4.

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...<mailto:sch...@gm...>]
Sent: Monday, January 21, 2013 11:15 AM
To: Ravishankar, Chandan
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe still has support for java 5 according to the ChangeLog and Bug 2962599.

On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Hi All,

Please let me know if you think it is worth to invest time in this area or if any other alternatives.

Regards,
Chandan

From: Ravishankar, Chandan
Sent: Thursday, January 17, 2013 6:33 PM
To: 'cob...@li...<mailto:cob...@li...>'
Subject: Cobertura 1.9 performance improvements

Hi All,

I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.

The software becomes slow when I run with the instrumented classes.

I wanted to see if I can optimize cobertura and still use it on Java 1.4.

I see in the latest versions we use concurrent collections instead of synchronized ones.

Any other good starting points?

Regards,
Chandan Ravishankar | Desk: 64529 | Cell: +91 994 550 1674<tel:%2B91%20994%20550%201674>


________________________________

This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the pos...@nd...<mailto:pos...@nd...> and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com<http://www.nds.com>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Steve C. <sch...@gm...>]

I was actually able to compile the latest version of cobertura using javac
1.4 as an argument. I just checked out the latest version of the source
code: http://cobertura.svn.sourceforge.net/viewvc/cobertura/trunk/cobertura/
and
opened the build.xml file, changed all the javac1.5 versions to 1.4, ran
the default ant target and had no compilation issues.


On Sun, Jan 20, 2013 at 11:47 PM, Ravishankar, Chandan <Cha...@nd...>wrote:

>  Hi Steve,****
>
> ** **
>
> Thanks for the reply. Unfortunately that is not possible.****
>
> ** **
>
> To work on Java 5 we need to port new JVM to our device and it won’t be
> possible as we have many constraints L.****
>
> ** **
>
> So the only option for me is to use 1.9 with Java 1.4.****
>
> ** **
>
> Regards,****
>
> Chandan****
>
> ** **
>
> *From:* Steve Christou [mailto:sch...@gm...]
> *Sent:* Monday, January 21, 2013 11:15 AM
> *To:* Ravishankar, Chandan
> *Cc:* cob...@li...
> *Subject:* Re: [Cobertura-devel] Cobertura 1.9 performance improvements***
> *
>
> ** **
>
> Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe
> still has support for java 5 according to the ChangeLog and Bug 2962599.**
> **
>
> ** **
>
> On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...>
> wrote:****
>
> Hi All,****
>
>  ****
>
> Please let me know if you think it is worth to invest time in this area or
> if any other alternatives.****
>
>  ****
>
> Regards,****
>
> Chandan****
>
>  ****
>
> *From:* Ravishankar, Chandan
> *Sent:* Thursday, January 17, 2013 6:33 PM
> *To:* 'cob...@li...'
> *Subject:* Cobertura 1.9 performance improvements****
>
>  ****
>
> Hi All,****
>
>  ****
>
> I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.****
>
>  ****
>
> The software becomes slow when I run with the instrumented classes.****
>
>  ****
>
> I wanted to see if I can optimize cobertura and still use it on Java 1.4.*
> ***
>
>  ****
>
> I see in the latest versions we use concurrent collections instead of
> synchronized ones.****
>
>  ****
>
> Any other good starting points? ****
>
>  ****
>
> Regards,****
>
> *Chandan Ravishankar* | Desk: 64529 | Cell: +91 994 550 1674****
>
>  ****
>
> ** **
>  ------------------------------
>
>
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> pos...@nd... and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes.
> To protect the environment please do not print this e-mail unless
> necessary.
>
> An NDS Group Limited company. www.nds.com****
>
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel****
>
> ** **
>

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Ravishankar, C. <Cha...@nd...>]

Hi Steve,

Thanks for the reply. Unfortunately that is not possible.

To work on Java 5 we need to port new JVM to our device and it won't be possible as we have many constraints :(.

So the only option for me is to use 1.9 with Java 1.4.

Regards,
Chandan

From: Steve Christou [mailto:sch...@gm...]
Sent: Monday, January 21, 2013 11:15 AM
To: Ravishankar, Chandan
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Cobertura 1.9 performance improvements

Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe still has support for java 5 according to the ChangeLog and Bug 2962599.

On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...<mailto:Cha...@nd...>> wrote:
Hi All,

Please let me know if you think it is worth to invest time in this area or if any other alternatives.

Regards,
Chandan

From: Ravishankar, Chandan
Sent: Thursday, January 17, 2013 6:33 PM
To: 'cob...@li...<mailto:cob...@li...>'
Subject: Cobertura 1.9 performance improvements

Hi All,

I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.

The software becomes slow when I run with the instrumented classes.

I wanted to see if I can optimize cobertura and still use it on Java 1.4.

I see in the latest versions we use concurrent collections instead of synchronized ones.

Any other good starting points?

Regards,
Chandan Ravishankar | Desk: 64529 | Cell: +91 994 550 1674<tel:%2B91%20994%20550%201674>


________________________________

This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the pos...@nd...<mailto:pos...@nd...> and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com<http://www.nds.com>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET<http://ASP.NET>, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Steve C. <sch...@gm...>]

Would it be possible to upgrade to using Java 5? Version 1.9.4.1 I believe
still has support for java 5 according to the ChangeLog and Bug 2962599.


On Sun, Jan 20, 2013 at 11:31 PM, Ravishankar, Chandan <Cha...@nd...>wrote:

>  Hi All,
>
>
>
> Please let me know if you think it is worth to invest time in this area or
> if any other alternatives.
>
>
>
> Regards,
>
> Chandan
>
>
>
> *From:* Ravishankar, Chandan
> *Sent:* Thursday, January 17, 2013 6:33 PM
> *To:* 'cob...@li...'
> *Subject:* Cobertura 1.9 performance improvements
>
>
>
> Hi All,
>
>
>
> I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.
>
>
>
> The software becomes slow when I run with the instrumented classes.
>
>
>
> I wanted to see if I can optimize cobertura and still use it on Java 1.4.
>
>
>
> I see in the latest versions we use concurrent collections instead of
> synchronized ones.
>
>
>
> Any other good starting points?
>
>
>
> Regards,
>
> *Chandan Ravishankar* | Desk: 64529 | Cell: +91 994 550 1674
>
>
>
> ------------------------------
>
> This message is confidential and intended only for the addressee. If you
> have received this message in error, please immediately notify the
> pos...@nd... and delete it from your system as well as any copies.
> The content of e-mails as well as traffic data may be monitored by NDS for
> employment and security purposes.
> To protect the environment please do not print this e-mail unless
> necessary.
>
> An NDS Group Limited company. www.nds.com
>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>

Re: [Cobertura-devel] Cobertura 1.9 performance improvements

[Ravishankar, C. <Cha...@nd...>]

Hi All,

Please let me know if you think it is worth to invest time in this area or if any other alternatives.

Regards,
Chandan

From: Ravishankar, Chandan
Sent: Thursday, January 17, 2013 6:33 PM
To: 'cob...@li...'
Subject: Cobertura 1.9 performance improvements

Hi All,

I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.

The software becomes slow when I run with the instrumented classes.

I wanted to see if I can optimize cobertura and still use it on Java 1.4.

I see in the latest versions we use concurrent collections instead of synchronized ones.

Any other good starting points?

Regards,
Chandan Ravishankar | Desk: 64529 | Cell: +91 994 550 1674


________________________________

This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the pos...@nd... and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com

[Cobertura-devel] Cobertura 1.9 performance improvements

[Ravishankar, C. <Cha...@nd...>]

Hi All,

I am using cobertura 1.9 (As we use Java 1.4) for the code coverage.

The software becomes slow when I run with the instrumented classes.

I wanted to see if I can optimize cobertura and still use it on Java 1.4.

I see in the latest versions we use concurrent collections instead of synchronized ones.

Any other good starting points?

Regards,
Chandan Ravishankar | Desk: 64529 | Cell: +91 994 550 1674


________________________________

This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the pos...@nd... and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes.
To protect the environment please do not print this e-mail unless necessary.

An NDS Group Limited company. www.nds.com

Re: [Cobertura-devel] report says code block isn't tested incorrectly

[Steve C. <sch...@gm...>]

For cobertura 2.0 I will try implementing a feature to better diagnose
missing branch coverage.
On Dec 21, 2012 11:50 AM, "KARR, DAVID" <dk...@at...> wrote:

>  And you can tell this from the occurrence counts in the margin.  It’s
> getting to both if bodies.****
>
> ** **
>
> This is one situation where the coloring provided by EclEmma is a little
> bit clearer.  Instead of just using green and red, it uses yellow to color
> lines with branches where not all of the branches have been taken.****
>
> ** **
>
> *From:* John W. Lewis [mailto:Joh...@sa...]
> *Sent:* Friday, December 21, 2012 6:50 AM
> *To:* Mark Schrijver; cob...@li...
> *Subject:* Re: [Cobertura-devel] report says code block isn't tested
> incorrectly****
>
> ** **
>
> ** **
>
> It is complaining that you don’t have a test when the type != BUY.   The
> type would also have to not equal SELL because it would not get to the
> second if statement if it was equal to SELL.   So, in other words you need
> a test where type != BUY and type != SELL.****
>
> ** **
>
> ** **
>
> *From:* Mark Schrijver [mailto:ra...@ra... <ra...@ra...>]
> *Sent:* Thursday, December 20, 2012 4:34 PM
> *To:* cob...@li...
> *Subject:* [Cobertura-devel] report says code block isn't tested
> incorrectly****
>
> ** **
>
> Hello,
>
> First off, great toolkit.
> That said, I do have a question. I've got the whole instrumentation, test
> and report task setup done. All that works like a charm, and I get really
> nice reports. But in the report for one of my tested classes, it states a
> piece of code isn't tested. When I step through the testcase though, I can
> see that piece of code being hit.
>
> Here's my Java method:
>
> public void setOrder(Order order) {
>         if (order.getType() == Order.TYPE.SELL) {
>             sellOrders.put(order.getId(), order);
>         } else if (order.getType() == Order.TYPE.BUY) {
>             buyOrders.put(order.getId(), order);
>         }
>     }
>
> And here's my test code:
>
> @Test
>     public void testSetOrder() {
>         Market market = new Market(1L, "Apeldoorn");
>         Resource metalResource = new Resource(1L, "metal", "Metal", 5F,
> 5F);
>         assertEquals("Invalid number of SELL orders", new Integer(0), new
> Integer(market.
>                 getSellOrders().size()));
>         assertEquals("Invalid number of buy orders", new Integer(0), new
> Integer(market.
>                 getBuyOrders().size()));
>         market.setOrder(new Order(TYPE.SELL, 1L, 15, metalResource, 1.5F,
> 1L));
>         assertEquals("Invalid number of SELL orders", new Integer(1), new
> Integer(market.
>                 getSellOrders().size()));
>         assertEquals("Invalid number of buy orders", new Integer(0), new
> Integer(market.
>                 getBuyOrders().size()));
>         market.setOrder(new Order(TYPE.BUY, 2L, 15, metalResource, 1.5F,
> 1L));
>         assertEquals("Invalid number of BUY orders", new Integer(1), new
> Integer(market.
>                 getSellOrders().size()));
>         assertEquals("Invalid number of buy orders", new Integer(1), new
> Integer(market.
>                 getBuyOrders().size()));
>     }
>
> As you can see, I call the setOrder both with an Order of type SELL and of
> type BUY. But the report on the setOrder method clearly states the second
> if statement is never covered by my test.
>
> ****
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>
>

Re: [Cobertura-devel] report says code block isn't tested incorrectly

[KARR, D. <dk...@at...>]

And you can tell this from the occurrence counts in the margin.  It's getting to both if bodies.

This is one situation where the coloring provided by EclEmma is a little bit clearer.  Instead of just using green and red, it uses yellow to color lines with branches where not all of the branches have been taken.

From: John W. Lewis [mailto:Joh...@sa...]
Sent: Friday, December 21, 2012 6:50 AM
To: Mark Schrijver; cob...@li...
Subject: Re: [Cobertura-devel] report says code block isn't tested incorrectly


It is complaining that you don't have a test when the type != BUY.   The type would also have to not equal SELL because it would not get to the second if statement if it was equal to SELL.   So, in other words you need a test where type != BUY and type != SELL.


From: Mark Schrijver [mailto:ra...@ra...]
Sent: Thursday, December 20, 2012 4:34 PM
To: cob...@li...<mailto:cob...@li...>
Subject: [Cobertura-devel] report says code block isn't tested incorrectly

Hello,

First off, great toolkit.
That said, I do have a question. I've got the whole instrumentation, test and report task setup done. All that works like a charm, and I get really nice reports. But in the report for one of my tested classes, it states a piece of code isn't tested. When I step through the testcase though, I can see that piece of code being hit.

Here's my Java method:

public void setOrder(Order order) {
        if (order.getType() == Order.TYPE.SELL) {
            sellOrders.put(order.getId(), order);
        } else if (order.getType() == Order.TYPE.BUY) {
            buyOrders.put(order.getId(), order);
        }
    }

And here's my test code:

@Test
    public void testSetOrder() {
        Market market = new Market(1L, "Apeldoorn");
        Resource metalResource = new Resource(1L, "metal", "Metal", 5F, 5F);
        assertEquals("Invalid number of SELL orders", new Integer(0), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(0), new Integer(market.
                getBuyOrders().size()));
        market.setOrder(new Order(TYPE.SELL, 1L, 15, metalResource, 1.5F, 1L));
        assertEquals("Invalid number of SELL orders", new Integer(1), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(0), new Integer(market.
                getBuyOrders().size()));
        market.setOrder(new Order(TYPE.BUY, 2L, 15, metalResource, 1.5F, 1L));
        assertEquals("Invalid number of BUY orders", new Integer(1), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(1), new Integer(market.
                getBuyOrders().size()));
    }

As you can see, I call the setOrder both with an Order of type SELL and of type BUY. But the report on the setOrder method clearly states the second if statement is never covered by my test.

Re: [Cobertura-devel] report says code block isn't tested incorrectly

[John W. L. <Joh...@sa...>]

It is complaining that you don't have a test when the type != BUY.   The type would also have to not equal SELL because it would not get to the second if statement if it was equal to SELL.   So, in other words you need a test where type != BUY and type != SELL.


From: Mark Schrijver [mailto:ra...@ra...]
Sent: Thursday, December 20, 2012 4:34 PM
To: cob...@li...
Subject: [Cobertura-devel] report says code block isn't tested incorrectly

Hello,

First off, great toolkit.
That said, I do have a question. I've got the whole instrumentation, test and report task setup done. All that works like a charm, and I get really nice reports. But in the report for one of my tested classes, it states a piece of code isn't tested. When I step through the testcase though, I can see that piece of code being hit.

Here's my Java method:

public void setOrder(Order order) {
        if (order.getType() == Order.TYPE.SELL) {
            sellOrders.put(order.getId(), order);
        } else if (order.getType() == Order.TYPE.BUY) {
            buyOrders.put(order.getId(), order);
        }
    }

And here's my test code:

@Test
    public void testSetOrder() {
        Market market = new Market(1L, "Apeldoorn");
        Resource metalResource = new Resource(1L, "metal", "Metal", 5F, 5F);
        assertEquals("Invalid number of SELL orders", new Integer(0), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(0), new Integer(market.
                getBuyOrders().size()));
        market.setOrder(new Order(TYPE.SELL, 1L, 15, metalResource, 1.5F, 1L));
        assertEquals("Invalid number of SELL orders", new Integer(1), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(0), new Integer(market.
                getBuyOrders().size()));
        market.setOrder(new Order(TYPE.BUY, 2L, 15, metalResource, 1.5F, 1L));
        assertEquals("Invalid number of BUY orders", new Integer(1), new Integer(market.
                getSellOrders().size()));
        assertEquals("Invalid number of buy orders", new Integer(1), new Integer(market.
                getBuyOrders().size()));
    }

As you can see, I call the setOrder both with an Order of type SELL and of type BUY. But the report on the setOrder method clearly states the second if statement is never covered by my test.

[Cobertura-devel] report says code block isn't tested incorrectly

[Mark S. <ra...@ra...>]

Hello,

First off, great toolkit.
That said, I do have a question. I've got the whole instrumentation, 
test and report task setup done. All that works like a charm, and I get 
really nice reports. But in the report for one of my tested classes, it 
states a piece of code isn't tested. When I step through the testcase 
though, I can see that piece of code being hit.

Here's my Java method:

public void setOrder(Order order) {
         if (order.getType() == Order.TYPE.SELL) {
             sellOrders.put(order.getId(), order);
         } else if (order.getType() == Order.TYPE.BUY) {
             buyOrders.put(order.getId(), order);
         }
     }

And here's my test code:

@Test
     public void testSetOrder() {
         Market market = new Market(1L, "Apeldoorn");
         Resource metalResource = new Resource(1L, "metal", "Metal", 5F, 
5F);
         assertEquals("Invalid number of SELL orders", new Integer(0), 
new Integer(market.
                 getSellOrders().size()));
         assertEquals("Invalid number of buy orders", new Integer(0), 
new Integer(market.
                 getBuyOrders().size()));
         market.setOrder(new Order(TYPE.SELL, 1L, 15, metalResource, 
1.5F, 1L));
         assertEquals("Invalid number of SELL orders", new Integer(1), 
new Integer(market.
                 getSellOrders().size()));
         assertEquals("Invalid number of buy orders", new Integer(0), 
new Integer(market.
                 getBuyOrders().size()));
         market.setOrder(new Order(TYPE.BUY, 2L, 15, metalResource, 
1.5F, 1L));
         assertEquals("Invalid number of BUY orders", new Integer(1), 
new Integer(market.
                 getSellOrders().size()));
         assertEquals("Invalid number of buy orders", new Integer(1), 
new Integer(market.
                 getBuyOrders().size()));
     }

As you can see, I call the setOrder both with an Order of type SELL and 
of type BUY. But the report on the setOrder method clearly states the 
second if statement is never covered by my test.

Re: [Cobertura-devel] Issues using Tomcat

[Steve C. <sch...@gm...>]

Take look at the FAQ page (http://cobertura.sourceforge.net/faq.html) the
section about Using cobertura with web application. I have found that
deploying web applications, sometimes if it can't find the cobertura.ser
file it will generate the report on another part of the machine if you
never set -Dnet.sourceforge.cobertura.datafile=  for all the jvms. If you
want to verify, make sure while you're running your junits, open process
explorer and make sure that variable is being set.

Thanks,
Steve.


On Wed, Dec 12, 2012 at 12:06 AM, Himani Khanna <him...@gm...>wrote:

> Hi,
>
> I have an automation test project using JUNIT to construct api's and
> sends request to the app deployed in tomcat. While executing the test
> cases i wanted to check for the code coverage/code hit during the
> execution of test cases. I followed the following steps but my reports
> are not showing any coverage details and tomcat logs show
>
> Cobertura: Loaded information on 189 classes.
> Cobertura: Saved information on 189 classes.
>
> No prints for flushing data.
>
> Steps used :
> 1) Compile the app folder
> 2) Instrument the class files, and cobertura.ser is created in present
> working directory
> 3) Create jar's and wars with instrumented files and deploy it in tomcat
> 4) Copy the cobertura.jar to the WEB-INF/lib of app
> 5) Tomcat shows : Cobertura Loaded information on X files
> 6) Run the test case which invokes the api and response is generated
> in app and handled by test case
> 7) Shutdown the tomcat server
> 8) Generate reports by using present working directories cobertura.ser
> file - 0% coverage shown
>
> Could the reason be a race condition between cobertura shutdown and
> tomcat server shutdown?
> On restart of tomcat server with same cobertura.ser will the data not
> be flushed for previous tests coverage as cleanup of cobertura.ser is
> not done ?
>
> Please help me understand above issues cause
>
> Regards
> Himani Khanna
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>

[Cobertura-devel] Bean registration error upon launching instrumented task

[tom.barrett <tom...@ja...>]

We build about a dozen different .wars that we launch in a tomcat container. 
W/ the exception of our "batch" app/.war, everything works fine.  Our system
architect suggested there may be a bug in cobertura (as the "batch" app runs
fine if not instrumented).  A partial snapshot from splunk is below.

Anyone seen anything similar (I couldn't find such in the archives) or have
suggestions?

Many thanks.

2012-10-1811:57:00,960 [yamaha05:54280main] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/batch]
[null] [env=qa2;key=;c1=;] - Exception sending context initialized
eventtolistener instance of class
org.springframework.web.context.ContextLoaderListener
org.springframework.beans.factory.BeanCreationException:Errorcreating bean
with name 'batch.jmxExporter' defined in class path resource
[BatchApp-jmx.xml]:Invocationof init method failed; nestedexception
isorg.springframework.jmx.export.UnableToRegisterMBeanException:Unable
toregister MBean
[com.jasperwireless.batch.flexiblebilling.FlexibleBillingBatch@5c98c2f2]
with key 'Jasper:type=batch,name=flexibleBillingBatch'; nested exception is
org.springframework.jmx.export.MBeanExportException:Couldnot create
ModelMBean for managedresource
[com.jasperwireless.batch.flexiblebilling.FlexibleBillingBatch@5c98c2f2]
with key 'Jasper:type=batch,name=flexibleBillingBatch'; nested exception is
java.lang.IllegalArgumentException:MetadataMBeanInfoAssemblerdoes not
support JDKdynamic proxies - export the target beans directly or useCGLIB
proxies instead
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1412)
        at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
      
atorg.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
        at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
        at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
        at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190)
        at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:574)
        at 
 
-- 
View this message in context: http://old.nabble.com/Bean-registration-error-upon-launching-instrumented-task-tp34781842p34781842.html
Sent from the cobertura-devel mailing list archive at Nabble.com.

[Cobertura-devel] Issues using Tomcat

[Himani K. <him...@gm...>]

Hi,

I have an automation test project using JUNIT to construct api's and
sends request to the app deployed in tomcat. While executing the test
cases i wanted to check for the code coverage/code hit during the
execution of test cases. I followed the following steps but my reports
are not showing any coverage details and tomcat logs show

Cobertura: Loaded information on 189 classes.
Cobertura: Saved information on 189 classes.

No prints for flushing data.

Steps used :
1) Compile the app folder
2) Instrument the class files, and cobertura.ser is created in present
working directory
3) Create jar's and wars with instrumented files and deploy it in tomcat
4) Copy the cobertura.jar to the WEB-INF/lib of app
5) Tomcat shows : Cobertura Loaded information on X files
6) Run the test case which invokes the api and response is generated
in app and handled by test case
7) Shutdown the tomcat server
8) Generate reports by using present working directories cobertura.ser
file - 0% coverage shown

Could the reason be a race condition between cobertura shutdown and
tomcat server shutdown?
On restart of tomcat server with same cobertura.ser will the data not
be flushed for previous tests coverage as cleanup of cobertura.ser is
not done ?

Please help me understand above issues cause

Regards
Himani Khanna

Re: [Cobertura-devel] how does flushing work, merge or overwrite?

[John W. L. <Joh...@sa...>]

It is a merge.

From: Daniel Zapata [mailto:dz...@gm...]
Sent: Thursday, December 06, 2012 1:34 PM
To: cob...@li...
Subject: [Cobertura-devel] how does flushing work, merge or overwrite?

I'm running cobertura in tomcat and using the coberturaFlush servlet to persist coverage data.  When you run the flush servlet, does that overwrite the existing cobertura.ser file, or does it merge the coverage data in memory with the existing cobertura file?

My use case is that I'm running cobertura in production and would like to set up some automation for periodically pulling the coverage results.  Depending on the answer to the above question, I may need to collect each cobertura.ser file generated and then do a merge on them all to get an accurate report.

Thanks,
Danny

[Cobertura-devel] how does flushing work, merge or overwrite?

[Daniel Z. <dz...@gm...>]

I'm running cobertura in tomcat and using the coberturaFlush servlet to
persist coverage data.  When you run the flush servlet, does that overwrite
the existing cobertura.ser file, or does it merge the coverage data in
memory with the existing cobertura file?

My use case is that I'm running cobertura in production and would like to
set up some automation for periodically pulling the coverage results.
 Depending on the answer to the above question, I may need to collect each
cobertura.ser file generated and then do a merge on them all to get an
accurate report.

Thanks,
Danny

Re: [Cobertura-devel] Use of cobertura in CI

[Gordon H. <gor...@ya...>]

Hi,

I think we got our wires crossed somewhere in this email thread.

My original question assumed that the war is built using the instrumented classes (which worried me) BUT David points out that cobertura creates the instrumented classes in target/generated-classes/cobertura and leaves the non-instrumented class files alone in target/classes.

The tests are run against the instrumented classes, test and test coverage results are recorded, then the war is built from the non-instrumented classes.

That's my understanding of things (ie. of the default maven behaviour).


I don't want instrumented classes being put into the war, so this is all good news for me :)

Someone please confirm I've understood things correctly?


Gord





>________________________________
> From: Steve Christou <sch...@gm...>
>To: John W. Lewis <Joh...@sa...> 
>Cc: "KARR, DAVID" <dk...@at...>; Gordon Harris <gor...@ya...>; "cob...@li..." <cob...@li...> 
>Sent: Friday, November 30, 2012 1:17:35 PM
>Subject: Re: [Cobertura-devel] Use of cobertura in CI
> 
>
>Well let me ask this, how are you deploying your war file? One solution I would do is in the deploy phase run a mvn clean package to clean the .war file and re-package it. Then you run the deploy after that. So for hudson/jenkins you have a second job that will be devoted to just deployment. What I would do is have one job that compiles and runs tests which displays results (cobertura and junit failures), and the final one that deploys.
>
>
>I think what John's talking about is overriding the deploy target for maven.
>
>
>
>On Fri, Nov 30, 2012 at 2:20 PM, John W. Lewis <Joh...@sa...> wrote:
>
> 
>>Right, and unfortunately, I don’t know enough about Maven to tell how to override the default behavior.   Somehow, you have to either use the “todir” mechanism that Steve mentioned, or you need to make a copy of the war before it is instrumented.
>> 
>>From:KARR, DAVID [mailto:dk...@at...] 
>>Sent: Friday, November 30, 2012 3:16 PM
>>To: Steve Christou; Gordon Harris
>>
>>Cc: cob...@li...
>>Subject: Re: [Cobertura-devel] Use of cobertura in CI
>> 
>>The default with Maven just “does the right thing”.  You’re right that you shouldn’t be deploying your instrumented classes, and that’s what the default provides for. Instrumentation will default to writing classes to “target/generated-classes/cobertura” instead of “target/classes”.
>> 
>>From:Steve Christou [mailto:sch...@gm...] 
>>Sent: Friday, November 30, 2012 11:52 AM
>>To: Gordon Harris
>>Cc: cob...@li...
>>Subject: Re: [Cobertura-devel] Use of cobertura in CI
>> 
>>You should never have to deploy an instrumented war file to a deployed environment. If i'm correct you are using maven to try and instrument. The cobertura ant task has a "todir" variable which creates a new file with instrumented code that way you have 2 different copies (one instrumented and one not instrumented).  You will need to investigate if maven can do this at all.
>> 
>>Thanks,
>>Steve.
>> 
>>On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...> wrote:
>>Hi,
>>
>>I am using cobertura for the first time. I'm trying to understand the right way to use it with Jenkins CI.
>>
>>We are writing a webapp. We have unit tests. Jenkins is setup to perform maven builds triggered by svn commits. The last step of a successful build is to deploy the generated war to a Tomcat instance for QA/demo purposes.
>>
>>I have Jenkins and the pom setup to run tests with cobertura. Jenkins shows lovely cobertura graphs :)
>>
>>My concern is that we should NOT be deploying the instrumented war to Tomcat. I do not need to track code coverage in the deployed environment. Tomcat should be running the app as may be released to production (ie. non-instrumented). But AFAIK there's only
 the one war being generated by the build.
>>
>>What's the right thing to do here? Am I mistaken about what the build generates? Is the solution to have separate projects running in Jenkins, one for cobertura and one for deploying to Tomcat? What do other people do?
>>
>>
>>Gord
>>
>>------------------------------------------------------------------------------
>>Keep yourself connected to Go Parallel:
>>TUNE You got it built. Now make it sing. Tune shows you how.
>>http://goparallel.sourceforge.net
>>_______________________________________________
>>Cobertura-devel mailing list
>>Cob...@li...
>>https://lists.sourceforge.net/lists/listinfo/cobertura-devel
>> 
>
>
>

Re: [Cobertura-devel] Use of cobertura in CI

[Steve C. <sch...@gm...>]

Well let me ask this, how are you deploying your war file? One solution I
would do is in the deploy phase run a mvn clean package to clean the .war
file and re-package it. Then you run the deploy after that. So for
hudson/jenkins you have a second job that will be devoted to just
deployment. What I would do is have one job that compiles and runs tests
which displays results (cobertura and junit failures), and the final one
that deploys.

I think what John's talking about is overriding the deploy target for maven.


On Fri, Nov 30, 2012 at 2:20 PM, John W. Lewis <Joh...@sa...> wrote:

>  ** **
>
> Right, and unfortunately, I don’t know enough about Maven to tell how to
> override the default behavior.   Somehow, you have to either use the
> “todir” mechanism that Steve mentioned, or you need to make a copy of the
> war before it is instrumented.****
>
> ** **
>
> *From:* KARR, DAVID [mailto:dk...@at...]
> *Sent:* Friday, November 30, 2012 3:16 PM
> *To:* Steve Christou; Gordon Harris
>
> *Cc:* cob...@li...
> *Subject:* Re: [Cobertura-devel] Use of cobertura in CI****
>
>  ** **
>
> The default with Maven just “does the right thing”.  You’re right that you
> shouldn’t be deploying your instrumented classes, and that’s what the
> default provides for. Instrumentation will default to writing classes to
> “target/generated-classes/cobertura” instead of “target/classes”.****
>
> ** **
>
> *From:* Steve Christou [mailto:sch...@gm...<sch...@gm...>]
>
> *Sent:* Friday, November 30, 2012 11:52 AM
> *To:* Gordon Harris
> *Cc:* cob...@li...
> *Subject:* Re: [Cobertura-devel] Use of cobertura in CI****
>
> ** **
>
> You should never have to deploy an instrumented war file to a deployed
> environment. If i'm correct you are using maven to try and instrument. The
> cobertura ant task has a "todir" variable which creates a new file with
> instrumented code that way you have 2 different copies (one instrumented
> and one not instrumented).  You will need to investigate if maven can do
> this at all.****
>
> ** **
>
> Thanks,****
>
> Steve.****
>
> ** **
>
> On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...>
> wrote:****
>
> Hi,
>
> I am using cobertura for the first time. I'm trying to understand the
> right way to use it with Jenkins CI.
>
> We are writing a webapp. We have unit tests. Jenkins is setup to perform
> maven builds triggered by svn commits. The last step of a successful build
> is to deploy the generated war to a Tomcat instance for QA/demo purposes.
>
> I have Jenkins and the pom setup to run tests with cobertura. Jenkins
> shows lovely cobertura graphs :)
>
> My concern is that we should NOT be deploying the instrumented war to
> Tomcat. I do not need to track code coverage in the deployed environment.
> Tomcat should be running the app as may be released to production (ie.
> non-instrumented). But AFAIK there's only the one war being generated by
> the build.
>
> What's the right thing to do here? Am I mistaken about what the build
> generates? Is the solution to have separate projects running in Jenkins,
> one for cobertura and one for deploying to Tomcat? What do other people do?
>
>
> Gord****
>
>
>
> ------------------------------------------------------------------------------
> Keep yourself connected to Go Parallel:
> TUNE You got it built. Now make it sing. Tune shows you how.
> http://goparallel.sourceforge.net
> _______________________________________________
> Cobertura-devel mailing list
> Cob...@li...
> https://lists.sourceforge.net/lists/listinfo/cobertura-devel****
>
> ** **
>

Re: [Cobertura-devel] Use of cobertura in CI

[KARR, D. <dk...@at...>]

I'm confused.  Why do you need to override the default behavior?  I thought you didn't want to deploy the instrumented classes?

From: John W. Lewis [mailto:Joh...@sa...]
Sent: Friday, November 30, 2012 12:20 PM
To: KARR, DAVID; Steve Christou; Gordon Harris
Cc: cob...@li...
Subject: RE: [Cobertura-devel] Use of cobertura in CI


Right, and unfortunately, I don't know enough about Maven to tell how to override the default behavior.   Somehow, you have to either use the "todir" mechanism that Steve mentioned, or you need to make a copy of the war before it is instrumented.

From: KARR, DAVID [mailto:dk...@at...]
Sent: Friday, November 30, 2012 3:16 PM
To: Steve Christou; Gordon Harris
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Use of cobertura in CI

The default with Maven just "does the right thing".  You're right that you shouldn't be deploying your instrumented classes, and that's what the default provides for. Instrumentation will default to writing classes to "target/generated-classes/cobertura" instead of "target/classes".

From: Steve Christou [mailto:sch...@gm...]
Sent: Friday, November 30, 2012 11:52 AM
To: Gordon Harris
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Use of cobertura in CI

You should never have to deploy an instrumented war file to a deployed environment. If i'm correct you are using maven to try and instrument. The cobertura ant task has a "todir" variable which creates a new file with instrumented code that way you have 2 different copies (one instrumented and one not instrumented).  You will need to investigate if maven can do this at all.

Thanks,
Steve.

On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...<mailto:gor...@ya...>> wrote:
Hi,

I am using cobertura for the first time. I'm trying to understand the right way to use it with Jenkins CI.

We are writing a webapp. We have unit tests. Jenkins is setup to perform maven builds triggered by svn commits. The last step of a successful build is to deploy the generated war to a Tomcat instance for QA/demo purposes.

I have Jenkins and the pom setup to run tests with cobertura. Jenkins shows lovely cobertura graphs :)

My concern is that we should NOT be deploying the instrumented war to Tomcat. I do not need to track code coverage in the deployed environment. Tomcat should be running the app as may be released to production (ie. non-instrumented). But AFAIK there's only the one war being generated by the build.

What's the right thing to do here? Am I mistaken about what the build generates? Is the solution to have separate projects running in Jenkins, one for cobertura and one for deploying to Tomcat? What do other people do?


Gord

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Use of cobertura in CI

[John W. L. <Joh...@sa...>]

Right, and unfortunately, I don't know enough about Maven to tell how to override the default behavior.   Somehow, you have to either use the "todir" mechanism that Steve mentioned, or you need to make a copy of the war before it is instrumented.

From: KARR, DAVID [mailto:dk...@at...]
Sent: Friday, November 30, 2012 3:16 PM
To: Steve Christou; Gordon Harris
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Use of cobertura in CI

The default with Maven just "does the right thing".  You're right that you shouldn't be deploying your instrumented classes, and that's what the default provides for. Instrumentation will default to writing classes to "target/generated-classes/cobertura" instead of "target/classes".

From: Steve Christou [mailto:sch...@gm...]
Sent: Friday, November 30, 2012 11:52 AM
To: Gordon Harris
Cc: cob...@li...<mailto:cob...@li...>
Subject: Re: [Cobertura-devel] Use of cobertura in CI

You should never have to deploy an instrumented war file to a deployed environment. If i'm correct you are using maven to try and instrument. The cobertura ant task has a "todir" variable which creates a new file with instrumented code that way you have 2 different copies (one instrumented and one not instrumented).  You will need to investigate if maven can do this at all.

Thanks,
Steve.

On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...<mailto:gor...@ya...>> wrote:
Hi,

I am using cobertura for the first time. I'm trying to understand the right way to use it with Jenkins CI.

We are writing a webapp. We have unit tests. Jenkins is setup to perform maven builds triggered by svn commits. The last step of a successful build is to deploy the generated war to a Tomcat instance for QA/demo purposes.

I have Jenkins and the pom setup to run tests with cobertura. Jenkins shows lovely cobertura graphs :)

My concern is that we should NOT be deploying the instrumented war to Tomcat. I do not need to track code coverage in the deployed environment. Tomcat should be running the app as may be released to production (ie. non-instrumented). But AFAIK there's only the one war being generated by the build.

What's the right thing to do here? Am I mistaken about what the build generates? Is the solution to have separate projects running in Jenkins, one for cobertura and one for deploying to Tomcat? What do other people do?


Gord

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel

Re: [Cobertura-devel] Use of cobertura in CI

[KARR, D. <dk...@at...>]

The default with Maven just "does the right thing".  You're right that you shouldn't be deploying your instrumented classes, and that's what the default provides for. Instrumentation will default to writing classes to "target/generated-classes/cobertura" instead of "target/classes".

From: Steve Christou [mailto:sch...@gm...]
Sent: Friday, November 30, 2012 11:52 AM
To: Gordon Harris
Cc: cob...@li...
Subject: Re: [Cobertura-devel] Use of cobertura in CI

You should never have to deploy an instrumented war file to a deployed environment. If i'm correct you are using maven to try and instrument. The cobertura ant task has a "todir" variable which creates a new file with instrumented code that way you have 2 different copies (one instrumented and one not instrumented).  You will need to investigate if maven can do this at all.

Thanks,
Steve.

On Fri, Nov 30, 2012 at 1:40 PM, Gordon Harris <gor...@ya...<mailto:gor...@ya...>> wrote:
Hi,

I am using cobertura for the first time. I'm trying to understand the right way to use it with Jenkins CI.

We are writing a webapp. We have unit tests. Jenkins is setup to perform maven builds triggered by svn commits. The last step of a successful build is to deploy the generated war to a Tomcat instance for QA/demo purposes.

I have Jenkins and the pom setup to run tests with cobertura. Jenkins shows lovely cobertura graphs :)

My concern is that we should NOT be deploying the instrumented war to Tomcat. I do not need to track code coverage in the deployed environment. Tomcat should be running the app as may be released to production (ie. non-instrumented). But AFAIK there's only the one war being generated by the build.

What's the right thing to do here? Am I mistaken about what the build generates? Is the solution to have separate projects running in Jenkins, one for cobertura and one for deploying to Tomcat? What do other people do?


Gord

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
TUNE You got it built. Now make it sing. Tune shows you how.
http://goparallel.sourceforge.net
_______________________________________________
Cobertura-devel mailing list
Cob...@li...<mailto:Cob...@li...>
https://lists.sourceforge.net/lists/listinfo/cobertura-devel