AW: Cobertura Maven Plugin works locally, but not in Jenkins

[Hohl, Gerrit]

Good morning Olivier, Stephen and John,

thanks for your replies.

It seems that I really had different Java's:

Local:

> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Program Files\Java\apache-maven-3.0.4
> Java version: 1.8.0_92, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_92\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"

Jenkins:

> Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
> Maven home: C:\Java\Maven\apache-maven-3.0.4
> Java version: 1.8.0_92, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jre1.8.0_92
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows server 2008 r2", version: "6.1", arch: "amd64", family: 
> "dos"

In the Jenkins job there was no Java explicitly set. So I did that.
I also deleted the local Maven repository on the Jenkins machine.
After that the same Java was used and everything worked fine.

Thanks again for your thoughts on my problem. :-)

Regards,
Gerrit
-Ursprüngliche Nachricht-
Von: Olivier Lamy [mailto:ol...@apache.org] 
Gesendet: Mittwoch, 13. Juli 2016 01:53
An: Maven Users List
Betreff: Re: Cobertura Maven Plugin works locally, but not in Jenkins

Hi
Do you have a sample project to reproduce the issue?

On Wednesday, 13 July 2016, Hohl, Gerrit <g.h...@aurenz.de> wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a 
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service 
> the Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't 
> see an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from 
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from 
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to 
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM 
> org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> --
> --
>
> Jul 12, 2016 3:43:15 PM 
> org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATIO

Re: Cobertura Maven Plugin works locally, but not in Jenkins

[Olivier Lamy]

Hi
Do you have a sample project to reproduce the issue?

On Wednesday, 13 July 2016, Hohl, Gerrit <g.h...@aurenz.de> wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service the
> Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't see
> an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION: BUILD FAILURE
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Total time: 35.284s
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Finished at: Tue Jul 12 15:43:15 CEST 2016
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Final Memory: 24M/174M
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> sessionEnded
>
> INFORMATION:
> 
>
> [...]
>
>
>
> And that is it. No errors, no stack traces, no messages.
>
> Jenkins uses the same Java version and same Maven version like my local
> build.
>
> We use an internal Nexus server as proxy for the artifacts.
>
> Means my local Maven installation as well as the one Jenkins uses are
> using the same artifact repository.
>
>
>
> Any ideas on this?
>
>
>
> Regards,
>
> Gerrit
>
>
>
>

-- 
Olivier

Re: Cobertura Maven Plugin works locally, but not in Jenkins

[Stephen Connolly]

Welcome to the evil one.

I have a blog post entitled "Maven job type considered evil"

Basically the issue is that Jenkins (via the evil one) is injecting a
remoting channel into your maven execution nd using that channel to both
modify and monitor the build.

One of the plugins that does this is the cobertura plugin. If it sees you
running cobertura it says "I'll have some of that, oh and let's tweak the
configuration while we are at it"

There may be a configuration option to tell the Jenkins cobertura plugin to
leave this job alone... Otherwise I recommend switching to either freestyle
or pipeline (got to love pipeline)

One of these days I'll get time to write my (long planned) replacement for
the evil one that does not do evil things... Until that day, you have a
tricky choice... Configure nothing and run the risk of it blowing up in
your face or use freestyle

On Tuesday 12 July 2016, Hohl, Gerrit <g.h...@aurenz.de> wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service the
> Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't see
> an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION: BUILD FAILURE
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Total time: 35.284s
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION: Finished at: Tue Jul 12 15:43:15 CEST 2016
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> 

Re: Cobertura Maven Plugin works locally, but not in Jenkins

[John Patrick]

I've had similar, where versions between locally and jenkins where
different. Question to ask yourself to see if you have checked;
) maven version used locally vs jenkins
) java version used locally vs jenkins
) operating system? same? both 32bit or 64bit?
) does your jenkins project have a private repo?
) do you define all plugins used within your pom?

I've had issues so now I always define all plugins used in the pom, I also
use the prerequisites to define maven version, plus the following
properties, maven.compiler.source, maven.compiler.target,
project.build.sourceEncoding, project.build.outputEncoding,
project.reporting.outputEncoding.

If your able to log into the jenkins box, if you manually execute the same
command as you do locally does it work?

Try deleting the jenkins repo.

After several issues, I always setup each jenkins project to use a separate
maven repo i.e. per workspace. Always define exact plugin version to use,
checking with versions:display-plugin-updates to make sure non are being
pulled in from the super pom. I've not had anymore issues, but saying that
I don't know if things have got better or not.

John


On 12 July 2016 at 15:48, Hohl, Gerrit <g.h...@aurenz.de> wrote:

> Hello everyone,
>
>
>
> I faced an odd problem today:
>
> We have a Maven Build which also includes the creation of a
> documentation.
>
> One of the plugins creating the reports is the Cobertura Maven Plugin.
>
> If I execute it on my local machine it works perfectly.
>
> Also the project has no code at all (it's more an Ant and aggregation
> project) it creates the documentation and also deploys it.
>
>
>
> But if I try to build the same project in our Jenkins build service the
> Maven jobs just days while trying to execute the Cobertura Maven Plugin.
>
> I added --debug, but also if the debug messages are enabled I don't see
> an error, stack trace or whatever in the log.
>
> On my local machine the output looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [DEBUG] Created new class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG] Importing foreign packages into class realm
> plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [DEBUG]   Imported:  < maven.api
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
> plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1
>
> [...]
>
>
>
> The output with the Jenkins server looks like this:
>
>
>
> [...]
>
> [DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin
>
> [DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
> the reporting.plugins section: 2.7
>
> [INFO] configuring report plugin
> org.codehaus.mojo:cobertura-maven-plugin:2.7
>
> [...]
>
> [DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:
>
> [DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile
>
> [DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile
>
> [DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile
>
> [...]
>
> [DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile
>
> [JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
> C:\.jenkins\jobs\xxx\site
>
>
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logResult
>
> INFORMATION: BUILD FAILURE
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> INFORMATION:
> 
>
> Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
> logStats
>
> IN

Cobertura Maven Plugin works locally, but not in Jenkins

[Hohl, Gerrit]

Hello everyone,

 

I faced an odd problem today:

We have a Maven Build which also includes the creation of a
documentation.

One of the plugins creating the reports is the Cobertura Maven Plugin.

If I execute it on my local machine it works perfectly.

Also the project has no code at all (it's more an Ant and aggregation
project) it creates the documentation and also deploys it.

 

But if I try to build the same project in our Jenkins build service the
Maven jobs just days while trying to execute the Cobertura Maven Plugin.

I added --debug, but also if the debug messages are enabled I don't see
an error, stack trace or whatever in the log.

On my local machine the output looks like this:

 

[...]

[DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin

[DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
the reporting.plugins section: 2.7

[INFO] configuring report plugin
org.codehaus.mojo:cobertura-maven-plugin:2.7

[...]

[DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:

[DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile

[DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile

[DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile

[DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile

[...]

[DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile

[DEBUG] Created new class realm
plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7

[DEBUG] Importing foreign packages into class realm
plugin>org.codehaus.mojo:cobertura-maven-plugin:2.7

[DEBUG]   Imported:  < maven.api

[DEBUG]   Imported: org.apache.maven.doxia.logging.Log <
plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1

[DEBUG]   Imported: org.apache.maven.doxia.logging.LogEnabled <
plugin>org.apache.maven.plugins:maven-site-plugin:3.5.1

[...]

 

The output with the Jenkins server looks like this:

 

[...]

[DEBUG] resolving version for org.codehaus.mojo:cobertura-maven-plugin

[DEBUG] resolved org.codehaus.mojo:cobertura-maven-plugin version from
the reporting.plugins section: 2.7

[INFO] configuring report plugin
org.codehaus.mojo:cobertura-maven-plugin:2.7

[...]

[DEBUG] org.codehaus.mojo:cobertura-maven-plugin:jar:2.7:

[DEBUG]net.sourceforge.cobertura:cobertura:jar:2.1.1:compile

[DEBUG]   org.ow2.asm:asm:jar:5.0.1:compile

[DEBUG]   org.ow2.asm:asm-tree:jar:5.0.1:compile

[DEBUG]   org.ow2.asm:asm-commons:jar:5.0.1:compile

[...]

[DEBUG]org.apache.maven.shared:maven-invoker:jar:2.0.11:compile

[JENKINS] Archiving site from c:\jenkins_data\workspace\target\site to
C:\.jenkins\jobs\xxx\site

 

Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logResult

INFORMATION:


Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logResult

INFORMATION: BUILD FAILURE

Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logStats

INFORMATION:


Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logStats

INFORMATION: Total time: 35.284s

Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logStats

INFORMATION: Finished at: Tue Jul 12 15:43:15 CEST 2016

Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
logStats

INFORMATION: Final Memory: 24M/174M

Jul 12, 2016 3:43:15 PM org.apache.maven.cli.event.ExecutionEventLogger
sessionEnded

INFORMATION:


[...]

 

And that is it. No errors, no stack traces, no messages.

Jenkins uses the same Java version and same Maven version like my local
build.

We use an internal Nexus server as proxy for the artifacts.

Means my local Maven installation as well as the one Jenkins uses are
using the same artifact repository.

 

Any ideas on this?

 

Regards,

Gerrit

 

[ANN] Cobertura Maven Plugin 2.7 Released

[Dennis Lundberg]

Hi,

The Mojo team is pleased to announce the release of the Cobertura
Maven Plugin version 2.7.

This plugin provides the features of Cobertura within the Maven 2  3
environment.

http://mojo.codehaus.org/cobertura-maven-plugin/

To get this update, simply specify the version in your project's
plugin configuration:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.7/version
/plugin

Release Notes

** Bug
* [MCOBERTURA-86] - no coverage reported for integration-test
* [MCOBERTURA-161] - cobertura report  appear a lot of  error :
JavaNCSS got an error while parsing the java file
* [MCOBERTURA-180] - Cobertura does not seem to work on OSX
* [MCOBERTURA-189] - Code coverage is not working with Java 8 sources
* [MCOBERTURA-190] - com.ibm.icu:icu:2.6.1 dependency makes
maven-enforcer-plugin checkSignatureRule to fail

** Improvement
* [MCOBERTURA-183] - Update Main class finding algorithm to handle
Cobertura releases after 2.0.3

** Task
* [MCOBERTURA-187] - Upgrade to Cobertura 2.1.1
* [MCOBERTURA-192] - Require Java 6

Enjoy,

The Mojo team.


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

What is the minimum required config for the Maven Cobertura plugin to instrument, run, and generate xml and html reports?

[KARR, DAVID]

I have a working configuration that runs unit tests with Cobertura using Maven. 
 I've always been a little mystified by Maven phases and how various plugins 
integrate with it (and I've read the user guide).

I'd like to understand the minimum required configuration to get Cobertura 
automatically running along with my unit tests, and generating both the XML and 
HTML outputs.  Answering this might require understanding what the Cobertura 
plugin goals do, but perhaps this is more of a Maven question.  I don't know.

For a long time, I had the following in the executions section:
---
executions
execution
idprepare/id
phaseprepare-package/phase
goals
goalclean/goal
goalcheck/goal
/goals
/execution
execution
idpackage/id
phasepackage/phase
goals
goalcobertura/goal
/goals
/execution
/executions
---

This works, but I've always been unclear on exactly what is required and what 
is just fluff.  By works, I mean that I see it instrument code, then run 
tests, and apparently generating output, because I find new versions of the XML 
and HTML reports after it completes.

Today I tried simplifying this to just the following:
-
executions
execution
goals
goalclean/goal
goalcheck/goal
goalcobertura/goal
/goals
/execution
/executions
-

This also seems to work perfectly fine.  I just don't know if there's really 
any difference, or not.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency

[Adrien Rivard]

Hi,

Try with artifactIdservlet-api-2.5/artifactId

spec version is in the artifactId.



On Tue, Jan 28, 2014 at 6:52 PM, Andrew Pennebaker apenneba...@42six.comwrote:

 I want to use Cobertura for code coverage, but its dependencies are
 interfering with my XML parsing and Jetty serving. I'm able to resolve most
 of these by using exclusion's, but Maven is somehow *still* putting one
 dependency in particular, jetty servlet-api, on the CLASSPATH.

 pom.xml:

 ...
   dependencies
 dependency
   groupIdnet.sourceforge.cobertura/groupId
   artifactIdcobertura/artifactId
   version2.0.3/version
   exclusions
 exclusion
   groupIdorg.mortbay.jetty/groupId
   artifactIdservlet-api/artifactId
 /exclusion
   /exclusions
 /dependency
   /dependencies
 ...

 As confirmed by `mvn dependency:tree`, cobertura is still bringing jetty's
 servlet-api onto the CLASSPATH. Am I doing something wrong?

 --
 Cheers,

 Andrew Pennebaker
 apenneba...@42six.com




-- 
Adrien Rivard

Re: Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency

[Andrew Pennebaker]

Thanks! I'll try that.

Oddly, mvn dependency:tree wasn't displaying the artifactId correctly.


On Wed, Jan 29, 2014 at 4:45 AM, Adrien Rivard adrien.riv...@gmail.comwrote:

 Hi,

 Try with artifactIdservlet-api-2.5/artifactId

 spec version is in the artifactId.



 On Tue, Jan 28, 2014 at 6:52 PM, Andrew Pennebaker apenneba...@42six.com
 wrote:

  I want to use Cobertura for code coverage, but its dependencies are
  interfering with my XML parsing and Jetty serving. I'm able to resolve
 most
  of these by using exclusion's, but Maven is somehow *still* putting one
  dependency in particular, jetty servlet-api, on the CLASSPATH.
 
  pom.xml:
 
  ...
dependencies
  dependency
groupIdnet.sourceforge.cobertura/groupId
artifactIdcobertura/artifactId
version2.0.3/version
exclusions
  exclusion
groupIdorg.mortbay.jetty/groupId
artifactIdservlet-api/artifactId
  /exclusion
/exclusions
  /dependency
/dependencies
  ...
 
  As confirmed by `mvn dependency:tree`, cobertura is still bringing
 jetty's
  servlet-api onto the CLASSPATH. Am I doing something wrong?
 
  --
  Cheers,
 
  Andrew Pennebaker
  apenneba...@42six.com
 



 --
 Adrien Rivard




-- 
Cheers,

Andrew Pennebaker
apenneba...@42six.com

cobertura-maven-plugin not creating .xml file as documented

[Andrew Pennebaker]

The online 
documentationhttp://mojo.codehaus.org/cobertura-maven-plugin/cobertura-mojo.htmlfor
cobertura-maven-plugin 2.6 says that coverage.xml is created if you
specify xml format. In reality, this only happens if you specify xml format
*and* run `mvn site`. `mvn cobertura:cobertura` never generates this file.

Could we amend the documentation to make this more clear (or even better,
go ahead and make `mvn cobertura:cobertura` generate this file)?

-- 
Cheers,

Andrew Pennebaker
apenneba...@42six.com

Re: cobertura-maven-plugin not creating .xml file as documented

[Anders Hammar]

That plugin is maintained by the Codehaus Mojo project. Please file a
ticket as described here:
http://mojo.codehaus.org/cobertura-maven-plugin/issue-tracking.html

Attaching a patch to the ticket will increase the likelihood of getting
this fixed quickly. (It doesn't have to be a patch file, you could just
state the suggested text change in the ticket itself.)

Thanks for improving the docs!

/Anders


On Wed, Jan 29, 2014 at 9:31 PM, Andrew Pennebaker apenneba...@42six.comwrote:

 The online documentation
 http://mojo.codehaus.org/cobertura-maven-plugin/cobertura-mojo.htmlfor
 cobertura-maven-plugin 2.6 says that coverage.xml is created if you
 specify xml format. In reality, this only happens if you specify xml format
 *and* run `mvn site`. `mvn cobertura:cobertura` never generates this file.

 Could we amend the documentation to make this more clear (or even better,
 go ahead and make `mvn cobertura:cobertura` generate this file)?

 --
 Cheers,

 Andrew Pennebaker
 apenneba...@42six.com

Can't exclude org.mortbay.jetty:servlet-api from cobertura dependency

[Andrew Pennebaker]

I want to use Cobertura for code coverage, but its dependencies are
interfering with my XML parsing and Jetty serving. I'm able to resolve most
of these by using exclusion's, but Maven is somehow *still* putting one
dependency in particular, jetty servlet-api, on the CLASSPATH.

pom.xml:

...
  dependencies
dependency
  groupIdnet.sourceforge.cobertura/groupId
  artifactIdcobertura/artifactId
  version2.0.3/version
  exclusions
exclusion
  groupIdorg.mortbay.jetty/groupId
  artifactIdservlet-api/artifactId
/exclusion
  /exclusions
/dependency
  /dependencies
...

As confirmed by `mvn dependency:tree`, cobertura is still bringing jetty's
servlet-api onto the CLASSPATH. Am I doing something wrong?

-- 
Cheers,

Andrew Pennebaker
apenneba...@42six.com

cobertura maven

[cyrduf]

Hi, 

I search how to solve all the ERROR and WARNING of may maven execution (see 
attached file toto.txt and extract of POM) 
= I launch mvn clean site 

I don’t find any topic with solution on forums. 


It's cobertura and com.sun.tools uses problems. 



Thanks for your help. 
Regards 


pom.xml
Description: XML document
[INFO] Scanning for projects...
[INFO] 
[INFO] 
[INFO] Building subproject0 1.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ subproject0 ---
[INFO] Deleting C:\Eclipse\K2\W\subproject0\target
[INFO] 
[INFO] --- maven-site-plugin:3.3:site (default-site) @ subproject0 ---
[INFO] configuring report plugin 
org.apache.maven.plugins:maven-project-info-reports-plugin:2.7
[INFO] configuring report plugin org.codehaus.mojo:cobertura-maven-plugin:2.6
[INFO] 
[INFO]  cobertura-maven-plugin:2.6:cobertura (report:cobertura) @ 
subproject0 
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
subproject0 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Eclipse\K2\W\subproject0\src\main\resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ subproject0 
---
[INFO] Compiling 1 source file to C:\Eclipse\K2\W\subproject0\target\classes
[INFO] 
[INFO] --- cobertura-maven-plugin:2.6:instrument (report:cobertura) @ 
subproject0 ---
[INFO] Cobertura 2.0.3 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file

[ERROR] janv. 28, 2014 12:14:27 PM 
net.sourceforge.cobertura.coveragedata.CoverageDataFileHandler saveCoverageData
Infos: Cobertura: Saved information on 1 classes.

[INFO] Instrumentation was successful.
[INFO] NOT adding cobertura ser file to attached artifacts list.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ 
subproject0 ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
C:\Eclipse\K2\W\subproject0\src\test\resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
subproject0 ---
[INFO] Compiling 4 source files to 
C:\Eclipse\K2\W\subproject0\target\test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ subproject0 ---
[INFO] Surefire report directory: 
C:\Eclipse\K2\W\subproject0\target\surefire-reports

---
 T E S T S
---
Running project.AppAUTOTest
Hello World!
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec
Running project.AppTest
Hello World!
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
Running project.AppUTest
Hello World!
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec

Results :

Tests run: 19, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO]  cobertura-maven-plugin:2.6:cobertura (report:cobertura) @ 
subproject0 
[INFO] Relativizing decoration links with respect to project URL: 
http://maven.apache.org
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 
skin.
[INFO] Generating Dependencies report--- 
maven-project-info-reports-plugin:2.7
[WARNING] Unable to process class 
com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer File 
d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar
org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in constant 
pool: 60
at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
at org.apache.bcel.classfile.ConstantPool.init(ConstantPool.java:67)
at 
org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
at 
org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92)
at 
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1454)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:536)
at 
org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:263)
at 
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:79)
at 
org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:186)
at 
org.apache.maven.reporting.AbstractMavenReport.generate

Re: cobertura maven

[Wayne Fay]

 I search how to solve all the ERROR and WARNING of may maven execution (see
 attached file toto.txt and extract of POM)
...
 It's cobertura and com.sun.tools uses problems.

[WARNING] Unable to process class
com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer
File 
d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar
org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in
constant pool: 60
 at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
 at org.apache.bcel.classfile.ConstantPool.init(ConstantPool.java:67)
 at org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
 at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
 at 
org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92)
 at 
org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255)

Looks like there is a problem with a class file in the icu4j-2.6.1.jar
file. Is there a newer version (2.6.2) available?

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura maven

[Alexander Kriegisch]

Search engines are your friend:
http://jira.codehaus.org/browse/MPIR-142
-- 
Alexander Kriegisch


Am 28.01.2014 um 22:59 schrieb Wayne Fay wayne...@gmail.com:

 I search how to solve all the ERROR and WARNING of may maven execution (see
 attached file toto.txt and extract of POM)
 ...
 It's cobertura and com.sun.tools uses problems.
 
 [WARNING] Unable to process class
 com/ibm/icu/impl/data/LocaleElements_zh__PINYIN.class in JarAnalyzer
 File 
 d:\Profiles\cdufrechou\.m2\repository\com\ibm\icu\icu4j\2.6.1\icu4j-2.6.1.jar
 org.apache.bcel.classfile.ClassFormatException: Invalid byte tag in
 constant pool: 60
 at org.apache.bcel.classfile.Constant.readConstant(Constant.java:146)
 at org.apache.bcel.classfile.ConstantPool.init(ConstantPool.java:67)
 at 
 org.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:222)
 at org.apache.bcel.classfile.ClassParser.parse(ClassParser.java:136)
 at 
 org.apache.maven.shared.jar.classes.JarClassesAnalysis.analyze(JarClassesAnalysis.java:92)
 at 
 org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:255)
 
 Looks like there is a problem with a class file in the icu4j-2.6.1.jar
 file. Is there a newer version (2.6.2) available?
 
 Wayne
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] Cobertura-Maven-Plugin 2.6 Released

[Steven Christou]

Hi,

The Mojo team is pleased to announce the release of the 
Cobertura-Maven-Plugin version 2.6.


This plugin provides the features of Cobertura within the Maven 2  3 
environment.


http://mojo.codehaus.org/cobertura-maven-plugin/

To get this update, simply specify the version in your project's plugin 
configuration:


plugin
   groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.6/version
/plugin


Release Notes

Upgrade to 2.0.3 of cobertura to allow for compatibility with java 7.
See https://github.com/cobertura/cobertura#version-203 versions 2.0 - 
2.0.3 release note information on what has changed since the last 
version of cobertura.



Enjoy,

The Mojo team.

Steven Christou

Cobertura multi-module report?

[Russell Gold]

Hi,

I see that the cobertura-maven-plugin has a parameter named, aggregate which 
I had hoped was similar to the aggregate report supported by the jar and 
javadoc plugins; however, when I enable it and disable inheritance, the report 
it generates is a blank page, so presumably I am not using it correctly. What 
is it supposed to do?

- Russ
-
Come read my webnovel, Take a Lemon http://www.takealemon.com, 
and listen to the Misfile radio play 
http://www.gold-family.us/audio/misfile.html!

[ANN] Cobertura Maven Plugin 2.5.2 Released

[Robert Scholte]

Hi,

The Mojo team is pleased to announce the release of the Cobertura Maven Plugin 
version 2.5.2. 
This plugin provides the features of Cobertura within the Maven 2  3 
environment.The report generated by this plugin is the result of executing the 
Cobertura tool against your compiled classes to help you determine how well the 
unit testing efforts have been, and can then be used to identify which parts of 
your Java program are lacking test coverage.
http://mojo.codehaus.org/cobertura-maven-plugin/

To get this update, simply specify the version in your project's plugin 
configuration: 
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.5.2/version
  /plugin


Release Notes - Maven 2.x Cobertura Plugin - Version 2.5.2

Bug


[MCOBERTURA-52] - Ignores and Excludes do nothing

[MCOBERTURA-150] - Aggregate parameter description doesn't contain 
'Since: 2.5'

[MCOBERTURA-151] - Regression comparing 2.5 and 2.5.1, NPE in 
CoberturaReportMojo


Enjoy,

The Mojo team.
 
Robert Scholte

Cobertura instrumentation in complex projects

[Jim McCaskey]

Hello all,

I have a fairly large build in which we use cobertura extensively to look at 
unit test code coverage for our project.  We also have separate integration 
tests that we would like to run using these instrumented binaries.  There is 
some good documentation on how to accomplish that here:

http://mojo.codehaus.org/cobertura-maven-plugin/instrumentingDeploymentArtifact.html

While that would work for a simple case, I'm struggling with trying to 
visualize how this would work in a complex case.  We have several separate 
builds that accumulate to make up the install package that we then push to our 
integration testing systems.  So everyone one of our couple hundred jar's which 
are fed from all these builds would need to be published to a Maven repository 
so that the install builds could pick them up.  But if I push them to my 
standard SNAPSHOT repository it would overwrite my existing non-instrumented 
versions.

We only envision needing this run on a nightly basis.  One suggestion that has 
been proposed is to do the publish with classifier thing and a profile that 
turns on cobertura.

https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html

Frankly, I'm not sure how that plumbing would work at this point, but I suppose 
it's possible.  Having said that, I think we just got done having that 
conversation on this list and the answer is that that is not the maven way.

I'm positive I'm not the first one in this boat.  Any thoughts?

-Jim





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: Cobertura instrumentation in complex projects

[Drury, Tim]

I've done exactly this and it's a pain.  I didn't want cobertura-instrumented 
jars from possibly infecting our production jars, so I have a Jenkins project 
that uses a private maven repo to build the entire product.  The final 
deliverable has a cobertura classifier and this is deployed to Artifactory.  
Another Jenkins project runs daily to pick up this artifact and deploy it to 
our integration test server.

However, all this is only the start of your problems.  Getting cobertura data 
files from the integration server in an automated fashion is very hard.  I had 
to write a web service to fetch the data from the (well documented) cobertura 
static class and return it to the caller.  After my integration test cases run, 
a maven plugin I wrote fetches that data, and I use the Jenkins cobertura 
plugin to turn it into html reports.  

I'm in the process of scrapping all that in favor of jacoco which instruments 
the code on-the-fly via a javaagent running in the container.

-tim

-Original Message-
From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] 
Sent: Tuesday, March 06, 2012 12:00 PM
To: 'users@maven.apache.org'
Subject: Cobertura instrumentation in complex projects

Hello all,

I have a fairly large build in which we use cobertura extensively to look at 
unit test code coverage for our project.  We also have separate integration 
tests that we would like to run using these instrumented binaries.  There is 
some good documentation on how to accomplish that here:

http://mojo.codehaus.org/cobertura-maven-plugin/instrumentingDeploymentArtifact.html

While that would work for a simple case, I'm struggling with trying to 
visualize how this would work in a complex case.  We have several separate 
builds that accumulate to make up the install package that we then push to our 
integration testing systems.  So everyone one of our couple hundred jar's which 
are fed from all these builds would need to be published to a Maven repository 
so that the install builds could pick them up.  But if I push them to my 
standard SNAPSHOT repository it would overwrite my existing non-instrumented 
versions.

We only envision needing this run on a nightly basis.  One suggestion that has 
been proposed is to do the publish with classifier thing and a profile that 
turns on cobertura.

https://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html

Frankly, I'm not sure how that plumbing would work at this point, but I suppose 
it's possible.  Having said that, I think we just got done having that 
conversation on this list and the answer is that that is not the maven way.

I'm positive I'm not the first one in this boat.  Any thoughts?

-Jim





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Jim McCaskey]

My take away here is that there is a bug in the cobertura plugin so I went 
ahead and opened it:

http://jira.codehaus.org/browse/MCOBERTURA-154

Any suggestions on how to work around it?  I guess I could do some hocus pocus 
with profiles...

-Jim

-Original Message-
From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of Robert 
Scholte
Sent: Monday, December 12, 2011 4:20 PM
To: users@maven.apache.org
Subject: RE: skip cobertura for a module


Exactly my conclusion

 

-Robert

 Date: Mon, 12 Dec 2011 22:09:53 +
 Subject: Re: skip cobertura for a module
 From: stephen.alan.conno...@gmail.com
 To: users@maven.apache.org
 
 Is it that the skip mojo is skipping the report but not the forked execution?
 
 On 12 December 2011 21:58, Jim McCaskey jim.mccas...@pervasive.com wrote:
  I created a small example of the problem and put it here:
 
  http://pastebin.com/QDhx2kVf
 
  Just run that pom.xml (I have tried Maven 2.2.1 and Maven 3.0.3) with this 
  command:
 
  mvn install cobertura:cobertura
 
  If it is truly skipping the cobertura plugin, you should only see this line 
  once:
 
  [echo] Running antrun plugin
 
  But you actually see it twice.
 
  I also tried this with -X as requested and the value appears to be set to 
  true below.
 
  [DEBUG] 
  ---
  [DEBUG] Goal: org.codehaus.mojo:cobertura-maven-plugin:2.5.1:instrument 
  (default-cli)
  [DEBUG] Style: Regular
  [DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
  configuration
  attach default-value=false${cobertura.attach}/attach
  classifier default-value=cobertura${cobertura.classifier}/classifier
  dataFile 
  default-value=${project.build.directory}/cobertura/cobertura.ser${cobertura.datafile}/dataFile
  forceMojoExecution 
  default-value=false${cobertura.force}/forceMojoExecution
  instrumentation${instrumentation}/instrumentation
  maxmem default-value=64m${cobertura.maxmem}/maxmem
  mojoExecution default-value=${mojoExecution}/
  pluginClasspathList default-value=${plugin.artifacts}/
  project default-value=${project}/
  quiet default-value=false${quiet}/quiet
  skip default-value=falsetrue/skip
  /configuration
 
  I'm not putting this into the reporting bit (yet).
 
  -Jim
 
  -Original Message-
  From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
  Robert Scholte
  Sent: Monday, December 12, 2011 1:57 PM
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
 
 
  If you run 'mvn cobertura:cobertura -X' (-X means debug-level logging) you 
  should see the used configuration.
 
  Can you confirm there's a skip-parameter and that its value is true?
 
  The pluginManagement doesn't work for reporting-plugins, so within the 
  reporting-section you are required to specify the version.
 
 
  -Robert
 
 
 
  From: jim.mccas...@pervasive.com
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
  Date: Mon, 12 Dec 2011 19:41:04 +
 
  Robert,
 
  Thanks much for the response. I have a parent pom that does just that in 
  its pluginManagement section. Under the heading of it never hurts to 
  try, I went ahead and tried putting this in the offending module:
 
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.5.1/version
  configuration
  skiptrue/skip
  /configuration
  /plugin
 
  It's still having the same problem.
 
  Thanks!
 
  -Jim
 
  -Original Message-
  From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
  Robert Scholte
  Sent: Monday, December 12, 2011 1:33 PM
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
 
 
  Try to set the version of the plugin to 2.5.1
 
  It is a good practice to always set the version for every plugin.
 
  Maven-3.0.x already warns you about it and it will probably be required 
  one day.
 
 
 
  -Robert
 
 
 
  ps. why not just run 'mvn install site'? This should already trigger these 
  plugins if you have defined them in the reporting-section.
 
   From: jim.mccas...@pervasive.com
   To: users@maven.apache.org
   Subject: skip cobertura for a module
   Date: Mon, 12 Dec 2011 19:19:40 +
  
   Hello all,
  
   I tried posting this on the codehaus user list but it won't accept my 
   e-mails. So let's try here:
  
   I'm having an issue with the cobertura plugin. I have a muti-module 
   build that I invoke like this on a nightly basis:
  
   mvn install site:site findbugs:findbugs cobertura:cobertura
  
   Now all of the modules in the build should build using cobertura, except 
   one. We have some custom stuff that is not entirely the Maven way and 
   want to ignore it for the sake of running cobertura (it does not contain 
   code anyway). Here's where I start hitting trouble. It seems that I 
   cannot get the skip to work. It always at least runs the prepare. It's 
   not corbertura that's failing (one of our in house

skip cobertura for a module

[Jim McCaskey]

Hello all,

I tried posting this on the codehaus user list but it won't accept my e-mails.  
So let's try here:

I'm having an issue with the cobertura plugin.  I have a muti-module build that 
I invoke like this on a nightly basis:

mvn install site:site findbugs:findbugs cobertura:cobertura

Now all of the modules in the build should build using cobertura, except one.  
We have some custom stuff that is not entirely the Maven way and want to 
ignore it for the sake of running cobertura (it does not contain code anyway).  
Here's where I start hitting trouble.  It seems that I cannot get the skip to 
work.  It always at least runs the prepare.  It's not corbertura that's failing 
(one of our in house plugins unfortunately), but I don't want that prepare to 
run at all.  

Ideally I would just use a skip like this:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
skiptrue/skip
/configuration
/plugin

But when I put that in, it still invokes cobertura.  At least I see it say this:

[INFO] Preparing cobertura:cobertura

And it proceeds to run all the other plugins again.  To be pedantic, I tried 
this as well:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
skiptrue/skip
/configuration
executions
execution
goals
goalclean/goal
goalcheck/goal
goalcobertura/goal
goaldump-datafile/goal
goalinstrument/goal
/goals
/execution
/executions
/plugin

But that had similar results.

I also tried putting this property in the pom:

properties
cobertura.skiptrue/cobertura.skip
/properties

Again, that did not stop it from running the prepare bit.  It seems to always 
run the prepare.  

How do I turn cobertura off for this one module?

-Jim


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Robert Scholte]

Try to set the version of the plugin to 2.5.1

It is a good practice to always set the version for every plugin. 

Maven-3.0.x already warns you about it and it will probably be required one day.

 

-Robert

 

ps. why not just run 'mvn install site'? This should already trigger these 
plugins if you have defined them in the reporting-section.

 From: jim.mccas...@pervasive.com
 To: users@maven.apache.org
 Subject: skip cobertura for a module
 Date: Mon, 12 Dec 2011 19:19:40 +
 
 Hello all,
 
 I tried posting this on the codehaus user list but it won't accept my 
 e-mails. So let's try here:
 
 I'm having an issue with the cobertura plugin. I have a muti-module build 
 that I invoke like this on a nightly basis:
 
 mvn install site:site findbugs:findbugs cobertura:cobertura
 
 Now all of the modules in the build should build using cobertura, except one. 
 We have some custom stuff that is not entirely the Maven way and want to 
 ignore it for the sake of running cobertura (it does not contain code 
 anyway). Here's where I start hitting trouble. It seems that I cannot get the 
 skip to work. It always at least runs the prepare. It's not corbertura that's 
 failing (one of our in house plugins unfortunately), but I don't want that 
 prepare to run at all. 
 
 Ideally I would just use a skip like this:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 configuration
 skiptrue/skip
 /configuration
 /plugin
 
 But when I put that in, it still invokes cobertura. At least I see it say 
 this:
 
 [INFO] Preparing cobertura:cobertura
 
 And it proceeds to run all the other plugins again. To be pedantic, I tried 
 this as well:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 configuration
 skiptrue/skip
 /configuration
 executions
 execution
 goals
 goalclean/goal
 goalcheck/goal
 goalcobertura/goal
 goaldump-datafile/goal
 goalinstrument/goal
 /goals
 /execution
 /executions
 /plugin
 
 But that had similar results.
 
 I also tried putting this property in the pom:
 
 properties
 cobertura.skiptrue/cobertura.skip
 /properties
 
 Again, that did not stop it from running the prepare bit. It seems to always 
 run the prepare. 
 
 How do I turn cobertura off for this one module?
 
 -Jim
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Jim McCaskey]

Robert,

Thanks much for the response.  I have a parent pom that does just that in its 
pluginManagement section.  Under the heading of it never hurts to try, I went 
ahead and tried putting this in the offending module:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.5.1/version
configuration
skiptrue/skip
/configuration
/plugin

It's still having the same problem.

Thanks!

-Jim

-Original Message-
From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of Robert 
Scholte
Sent: Monday, December 12, 2011 1:33 PM
To: users@maven.apache.org
Subject: RE: skip cobertura for a module


Try to set the version of the plugin to 2.5.1

It is a good practice to always set the version for every plugin. 

Maven-3.0.x already warns you about it and it will probably be required one day.

 

-Robert

 

ps. why not just run 'mvn install site'? This should already trigger these 
plugins if you have defined them in the reporting-section.

 From: jim.mccas...@pervasive.com
 To: users@maven.apache.org
 Subject: skip cobertura for a module
 Date: Mon, 12 Dec 2011 19:19:40 +
 
 Hello all,
 
 I tried posting this on the codehaus user list but it won't accept my 
 e-mails. So let's try here:
 
 I'm having an issue with the cobertura plugin. I have a muti-module build 
 that I invoke like this on a nightly basis:
 
 mvn install site:site findbugs:findbugs cobertura:cobertura
 
 Now all of the modules in the build should build using cobertura, except one. 
 We have some custom stuff that is not entirely the Maven way and want to 
 ignore it for the sake of running cobertura (it does not contain code 
 anyway). Here's where I start hitting trouble. It seems that I cannot get the 
 skip to work. It always at least runs the prepare. It's not corbertura that's 
 failing (one of our in house plugins unfortunately), but I don't want that 
 prepare to run at all. 
 
 Ideally I would just use a skip like this:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 configuration
 skiptrue/skip
 /configuration
 /plugin
 
 But when I put that in, it still invokes cobertura. At least I see it say 
 this:
 
 [INFO] Preparing cobertura:cobertura
 
 And it proceeds to run all the other plugins again. To be pedantic, I tried 
 this as well:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 configuration
 skiptrue/skip
 /configuration
 executions
 execution
 goals
 goalclean/goal
 goalcheck/goal
 goalcobertura/goal
 goaldump-datafile/goal
 goalinstrument/goal
 /goals
 /execution
 /executions
 /plugin
 
 But that had similar results.
 
 I also tried putting this property in the pom:
 
 properties
 cobertura.skiptrue/cobertura.skip
 /properties
 
 Again, that did not stop it from running the prepare bit. It seems to always 
 run the prepare. 
 
 How do I turn cobertura off for this one module?
 
 -Jim
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Drury, Tim]

I just looked at the cobertura maven source the other day, so I took another 
look.  skipMojo() is the first call in the instrument plugin and if skip is 
true it should log at INFO level: Skipping cobertura execution

While I don't have a solution to your issue, I can tell you that cobertura is 
definitely running on this module.

-tim

-Original Message-
From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] 
Sent: Monday, December 12, 2011 2:20 PM
To: 'users@maven.apache.org'
Subject: skip cobertura for a module

Hello all,

I tried posting this on the codehaus user list but it won't accept my e-mails.  
So let's try here:

I'm having an issue with the cobertura plugin.  I have a muti-module build that 
I invoke like this on a nightly basis:

mvn install site:site findbugs:findbugs cobertura:cobertura

Now all of the modules in the build should build using cobertura, except one.  
We have some custom stuff that is not entirely the Maven way and want to 
ignore it for the sake of running cobertura (it does not contain code anyway).  
Here's where I start hitting trouble.  It seems that I cannot get the skip to 
work.  It always at least runs the prepare.  It's not corbertura that's failing 
(one of our in house plugins unfortunately), but I don't want that prepare to 
run at all.  

Ideally I would just use a skip like this:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
skiptrue/skip
/configuration
/plugin

But when I put that in, it still invokes cobertura.  At least I see it say this:

[INFO] Preparing cobertura:cobertura

And it proceeds to run all the other plugins again.  To be pedantic, I tried 
this as well:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
skiptrue/skip
/configuration
executions
execution
goals
goalclean/goal
goalcheck/goal
goalcobertura/goal
goaldump-datafile/goal
goalinstrument/goal
/goals
/execution
/executions
/plugin

But that had similar results.

I also tried putting this property in the pom:

properties
cobertura.skiptrue/cobertura.skip
/properties

Again, that did not stop it from running the prepare bit.  It seems to always 
run the prepare.  

How do I turn cobertura off for this one module?

-Jim


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Robert Scholte]

If you run 'mvn cobertura:cobertura -X' (-X means debug-level logging) you 
should see the used configuration.

Can you confirm there's a skip-parameter and that its value is true?

The pluginManagement doesn't work for reporting-plugins, so within the 
reporting-section you are required to specify the version.
 

-Robert



 From: jim.mccas...@pervasive.com
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module
 Date: Mon, 12 Dec 2011 19:41:04 +
 
 Robert,
 
 Thanks much for the response. I have a parent pom that does just that in its 
 pluginManagement section. Under the heading of it never hurts to try, I 
 went ahead and tried putting this in the offending module:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 version2.5.1/version
 configuration
 skiptrue/skip
 /configuration
 /plugin
 
 It's still having the same problem.
 
 Thanks!
 
 -Jim
 
 -Original Message-
 From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
 Robert Scholte
 Sent: Monday, December 12, 2011 1:33 PM
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module
 
 
 Try to set the version of the plugin to 2.5.1
 
 It is a good practice to always set the version for every plugin. 
 
 Maven-3.0.x already warns you about it and it will probably be required one 
 day.
 
 
 
 -Robert
 
 
 
 ps. why not just run 'mvn install site'? This should already trigger these 
 plugins if you have defined them in the reporting-section.
 
  From: jim.mccas...@pervasive.com
  To: users@maven.apache.org
  Subject: skip cobertura for a module
  Date: Mon, 12 Dec 2011 19:19:40 +
  
  Hello all,
  
  I tried posting this on the codehaus user list but it won't accept my 
  e-mails. So let's try here:
  
  I'm having an issue with the cobertura plugin. I have a muti-module build 
  that I invoke like this on a nightly basis:
  
  mvn install site:site findbugs:findbugs cobertura:cobertura
  
  Now all of the modules in the build should build using cobertura, except 
  one. We have some custom stuff that is not entirely the Maven way and 
  want to ignore it for the sake of running cobertura (it does not contain 
  code anyway). Here's where I start hitting trouble. It seems that I cannot 
  get the skip to work. It always at least runs the prepare. It's not 
  corbertura that's failing (one of our in house plugins unfortunately), but 
  I don't want that prepare to run at all. 
  
  Ideally I would just use a skip like this:
  
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  /plugin
  
  But when I put that in, it still invokes cobertura. At least I see it say 
  this:
  
  [INFO] Preparing cobertura:cobertura
  
  And it proceeds to run all the other plugins again. To be pedantic, I tried 
  this as well:
  
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  executions
  execution
  goals
  goalclean/goal
  goalcheck/goal
  goalcobertura/goal
  goaldump-datafile/goal
  goalinstrument/goal
  /goals
  /execution
  /executions
  /plugin
  
  But that had similar results.
  
  I also tried putting this property in the pom:
  
  properties
  cobertura.skiptrue/cobertura.skip
  /properties
  
  Again, that did not stop it from running the prepare bit. It seems to 
  always run the prepare. 
  
  How do I turn cobertura off for this one module?
  
  -Jim
  
  
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
  
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: skip cobertura for a module

[Jim McCaskey]

I created a small example of the problem and put it here:

http://pastebin.com/QDhx2kVf

Just run that pom.xml (I have tried Maven 2.2.1 and Maven 3.0.3) with this 
command:

mvn install cobertura:cobertura

If it is truly skipping the cobertura plugin, you should only see this line 
once:

 [echo] Running antrun plugin

But you actually see it twice. 

I also tried this with -X as requested and the value appears to be set to true 
below.

[DEBUG] ---
[DEBUG] Goal:  
org.codehaus.mojo:cobertura-maven-plugin:2.5.1:instrument (default-cli)
[DEBUG] Style: Regular
[DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
configuration
  attach default-value=false${cobertura.attach}/attach
  classifier default-value=cobertura${cobertura.classifier}/classifier
  dataFile 
default-value=${project.build.directory}/cobertura/cobertura.ser${cobertura.datafile}/dataFile
  forceMojoExecution 
default-value=false${cobertura.force}/forceMojoExecution
  instrumentation${instrumentation}/instrumentation
  maxmem default-value=64m${cobertura.maxmem}/maxmem
  mojoExecution default-value=${mojoExecution}/
  pluginClasspathList default-value=${plugin.artifacts}/
  project default-value=${project}/
  quiet default-value=false${quiet}/quiet
  skip default-value=falsetrue/skip
/configuration

I'm not putting this into the reporting bit (yet).

-Jim

-Original Message-
From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of Robert 
Scholte
Sent: Monday, December 12, 2011 1:57 PM
To: users@maven.apache.org
Subject: RE: skip cobertura for a module


If you run 'mvn cobertura:cobertura -X' (-X means debug-level logging) you 
should see the used configuration.

Can you confirm there's a skip-parameter and that its value is true?

The pluginManagement doesn't work for reporting-plugins, so within the 
reporting-section you are required to specify the version.
 

-Robert



 From: jim.mccas...@pervasive.com
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module
 Date: Mon, 12 Dec 2011 19:41:04 +
 
 Robert,
 
 Thanks much for the response. I have a parent pom that does just that in its 
 pluginManagement section. Under the heading of it never hurts to try, I 
 went ahead and tried putting this in the offending module:
 
 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 version2.5.1/version
 configuration
 skiptrue/skip
 /configuration
 /plugin
 
 It's still having the same problem.
 
 Thanks!
 
 -Jim
 
 -Original Message-
 From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
 Robert Scholte
 Sent: Monday, December 12, 2011 1:33 PM
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module
 
 
 Try to set the version of the plugin to 2.5.1
 
 It is a good practice to always set the version for every plugin. 
 
 Maven-3.0.x already warns you about it and it will probably be required one 
 day.
 
 
 
 -Robert
 
 
 
 ps. why not just run 'mvn install site'? This should already trigger these 
 plugins if you have defined them in the reporting-section.
 
  From: jim.mccas...@pervasive.com
  To: users@maven.apache.org
  Subject: skip cobertura for a module
  Date: Mon, 12 Dec 2011 19:19:40 +
  
  Hello all,
  
  I tried posting this on the codehaus user list but it won't accept my 
  e-mails. So let's try here:
  
  I'm having an issue with the cobertura plugin. I have a muti-module build 
  that I invoke like this on a nightly basis:
  
  mvn install site:site findbugs:findbugs cobertura:cobertura
  
  Now all of the modules in the build should build using cobertura, except 
  one. We have some custom stuff that is not entirely the Maven way and 
  want to ignore it for the sake of running cobertura (it does not contain 
  code anyway). Here's where I start hitting trouble. It seems that I cannot 
  get the skip to work. It always at least runs the prepare. It's not 
  corbertura that's failing (one of our in house plugins unfortunately), but 
  I don't want that prepare to run at all. 
  
  Ideally I would just use a skip like this:
  
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  /plugin
  
  But when I put that in, it still invokes cobertura. At least I see it say 
  this:
  
  [INFO] Preparing cobertura:cobertura
  
  And it proceeds to run all the other plugins again. To be pedantic, I tried 
  this as well:
  
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  executions
  execution
  goals
  goalclean/goal
  goalcheck/goal
  goalcobertura/goal
  goaldump-datafile/goal
  goalinstrument/goal
  /goals
  /execution
  /executions
  /plugin
  
  But that had similar results.
  
  I also tried putting this property in the pom:
  
  properties

Re: skip cobertura for a module

[Stephen Connolly]

Is it that the skip mojo is skipping the report but not the forked execution?

On 12 December 2011 21:58, Jim McCaskey jim.mccas...@pervasive.com wrote:
 I created a small example of the problem and put it here:

 http://pastebin.com/QDhx2kVf

 Just run that pom.xml (I have tried Maven 2.2.1 and Maven 3.0.3) with this 
 command:

 mvn install cobertura:cobertura

 If it is truly skipping the cobertura plugin, you should only see this line 
 once:

     [echo] Running antrun plugin

 But you actually see it twice.

 I also tried this with -X as requested and the value appears to be set to 
 true below.

 [DEBUG] 
 ---
 [DEBUG] Goal:          
 org.codehaus.mojo:cobertura-maven-plugin:2.5.1:instrument (default-cli)
 [DEBUG] Style:         Regular
 [DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
 configuration
  attach default-value=false${cobertura.attach}/attach
  classifier default-value=cobertura${cobertura.classifier}/classifier
  dataFile 
 default-value=${project.build.directory}/cobertura/cobertura.ser${cobertura.datafile}/dataFile
  forceMojoExecution 
 default-value=false${cobertura.force}/forceMojoExecution
  instrumentation${instrumentation}/instrumentation
  maxmem default-value=64m${cobertura.maxmem}/maxmem
  mojoExecution default-value=${mojoExecution}/
  pluginClasspathList default-value=${plugin.artifacts}/
  project default-value=${project}/
  quiet default-value=false${quiet}/quiet
  skip default-value=falsetrue/skip
 /configuration

 I'm not putting this into the reporting bit (yet).

 -Jim

 -Original Message-
 From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
 Robert Scholte
 Sent: Monday, December 12, 2011 1:57 PM
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module


 If you run 'mvn cobertura:cobertura -X' (-X means debug-level logging) you 
 should see the used configuration.

 Can you confirm there's a skip-parameter and that its value is true?

 The pluginManagement doesn't work for reporting-plugins, so within the 
 reporting-section you are required to specify the version.


 -Robert



 From: jim.mccas...@pervasive.com
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module
 Date: Mon, 12 Dec 2011 19:41:04 +

 Robert,

 Thanks much for the response. I have a parent pom that does just that in its 
 pluginManagement section. Under the heading of it never hurts to try, I 
 went ahead and tried putting this in the offending module:

 plugin
 groupIdorg.codehaus.mojo/groupId
 artifactIdcobertura-maven-plugin/artifactId
 version2.5.1/version
 configuration
 skiptrue/skip
 /configuration
 /plugin

 It's still having the same problem.

 Thanks!

 -Jim

 -Original Message-
 From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
 Robert Scholte
 Sent: Monday, December 12, 2011 1:33 PM
 To: users@maven.apache.org
 Subject: RE: skip cobertura for a module


 Try to set the version of the plugin to 2.5.1

 It is a good practice to always set the version for every plugin.

 Maven-3.0.x already warns you about it and it will probably be required one 
 day.



 -Robert



 ps. why not just run 'mvn install site'? This should already trigger these 
 plugins if you have defined them in the reporting-section.

  From: jim.mccas...@pervasive.com
  To: users@maven.apache.org
  Subject: skip cobertura for a module
  Date: Mon, 12 Dec 2011 19:19:40 +
 
  Hello all,
 
  I tried posting this on the codehaus user list but it won't accept my 
  e-mails. So let's try here:
 
  I'm having an issue with the cobertura plugin. I have a muti-module build 
  that I invoke like this on a nightly basis:
 
  mvn install site:site findbugs:findbugs cobertura:cobertura
 
  Now all of the modules in the build should build using cobertura, except 
  one. We have some custom stuff that is not entirely the Maven way and 
  want to ignore it for the sake of running cobertura (it does not contain 
  code anyway). Here's where I start hitting trouble. It seems that I cannot 
  get the skip to work. It always at least runs the prepare. It's not 
  corbertura that's failing (one of our in house plugins unfortunately), but 
  I don't want that prepare to run at all.
 
  Ideally I would just use a skip like this:
 
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  /plugin
 
  But when I put that in, it still invokes cobertura. At least I see it say 
  this:
 
  [INFO] Preparing cobertura:cobertura
 
  And it proceeds to run all the other plugins again. To be pedantic, I 
  tried this as well:
 
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  configuration
  skiptrue/skip
  /configuration
  executions
  execution
  goals
  goalclean/goal
  goalcheck/goal
  goalcobertura/goal
  goaldump-datafile/goal
  goalinstrument/goal

RE: skip cobertura for a module

[Robert Scholte]

Exactly my conclusion

 

-Robert

 Date: Mon, 12 Dec 2011 22:09:53 +
 Subject: Re: skip cobertura for a module
 From: stephen.alan.conno...@gmail.com
 To: users@maven.apache.org
 
 Is it that the skip mojo is skipping the report but not the forked execution?
 
 On 12 December 2011 21:58, Jim McCaskey jim.mccas...@pervasive.com wrote:
  I created a small example of the problem and put it here:
 
  http://pastebin.com/QDhx2kVf
 
  Just run that pom.xml (I have tried Maven 2.2.1 and Maven 3.0.3) with this 
  command:
 
  mvn install cobertura:cobertura
 
  If it is truly skipping the cobertura plugin, you should only see this line 
  once:
 
  [echo] Running antrun plugin
 
  But you actually see it twice.
 
  I also tried this with -X as requested and the value appears to be set to 
  true below.
 
  [DEBUG] 
  ---
  [DEBUG] Goal: org.codehaus.mojo:cobertura-maven-plugin:2.5.1:instrument 
  (default-cli)
  [DEBUG] Style: Regular
  [DEBUG] Configuration: ?xml version=1.0 encoding=UTF-8?
  configuration
  attach default-value=false${cobertura.attach}/attach
  classifier default-value=cobertura${cobertura.classifier}/classifier
  dataFile 
  default-value=${project.build.directory}/cobertura/cobertura.ser${cobertura.datafile}/dataFile
  forceMojoExecution 
  default-value=false${cobertura.force}/forceMojoExecution
  instrumentation${instrumentation}/instrumentation
  maxmem default-value=64m${cobertura.maxmem}/maxmem
  mojoExecution default-value=${mojoExecution}/
  pluginClasspathList default-value=${plugin.artifacts}/
  project default-value=${project}/
  quiet default-value=false${quiet}/quiet
  skip default-value=falsetrue/skip
  /configuration
 
  I'm not putting this into the reporting bit (yet).
 
  -Jim
 
  -Original Message-
  From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
  Robert Scholte
  Sent: Monday, December 12, 2011 1:57 PM
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
 
 
  If you run 'mvn cobertura:cobertura -X' (-X means debug-level logging) you 
  should see the used configuration.
 
  Can you confirm there's a skip-parameter and that its value is true?
 
  The pluginManagement doesn't work for reporting-plugins, so within the 
  reporting-section you are required to specify the version.
 
 
  -Robert
 
 
 
  From: jim.mccas...@pervasive.com
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
  Date: Mon, 12 Dec 2011 19:41:04 +
 
  Robert,
 
  Thanks much for the response. I have a parent pom that does just that in 
  its pluginManagement section. Under the heading of it never hurts to 
  try, I went ahead and tried putting this in the offending module:
 
  plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.5.1/version
  configuration
  skiptrue/skip
  /configuration
  /plugin
 
  It's still having the same problem.
 
  Thanks!
 
  -Jim
 
  -Original Message-
  From: rfscho...@hotmail.com [mailto:rfscho...@hotmail.com] On Behalf Of 
  Robert Scholte
  Sent: Monday, December 12, 2011 1:33 PM
  To: users@maven.apache.org
  Subject: RE: skip cobertura for a module
 
 
  Try to set the version of the plugin to 2.5.1
 
  It is a good practice to always set the version for every plugin.
 
  Maven-3.0.x already warns you about it and it will probably be required 
  one day.
 
 
 
  -Robert
 
 
 
  ps. why not just run 'mvn install site'? This should already trigger these 
  plugins if you have defined them in the reporting-section.
 
   From: jim.mccas...@pervasive.com
   To: users@maven.apache.org
   Subject: skip cobertura for a module
   Date: Mon, 12 Dec 2011 19:19:40 +
  
   Hello all,
  
   I tried posting this on the codehaus user list but it won't accept my 
   e-mails. So let's try here:
  
   I'm having an issue with the cobertura plugin. I have a muti-module 
   build that I invoke like this on a nightly basis:
  
   mvn install site:site findbugs:findbugs cobertura:cobertura
  
   Now all of the modules in the build should build using cobertura, except 
   one. We have some custom stuff that is not entirely the Maven way and 
   want to ignore it for the sake of running cobertura (it does not contain 
   code anyway). Here's where I start hitting trouble. It seems that I 
   cannot get the skip to work. It always at least runs the prepare. It's 
   not corbertura that's failing (one of our in house plugins 
   unfortunately), but I don't want that prepare to run at all.
  
   Ideally I would just use a skip like this:
  
   plugin
   groupIdorg.codehaus.mojo/groupId
   artifactIdcobertura-maven-plugin/artifactId
   configuration
   skiptrue/skip
   /configuration
   /plugin
  
   But when I put that in, it still invokes cobertura. At least I see it 
   say this:
  
   [INFO] Preparing cobertura:cobertura
  
   And it proceeds to run all the other plugins again

Re: Can cobertura and surefire-report plugins be run without running the tests twice?

[Miguel Almeida]

Thank you for pointing out to that discussion.  Even though I don't agree
completely - if running the coverage tool Cobertura changes the status of
your tests, I'd say that in most likelihood the problem should be cobertura
and not your code or your test - I might live with running the cobertura
goal separately and even move it to the CI system: it delays quick feedback
to the developer locally anyway.

Miguel Almeida

On Mon, Sep 26, 2011 at 4:08 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 http://maven.40175.n5.nabble.com/Cobertura-and-Surefire-td3338334.html




 On 26 September 2011 15:46, Miguel Almeida migueldealme...@gmail.com
 wrote:
  I am using the cobertura plugin to create test coverage reports, and
  surefire-report for test reports. See [1] for my maven 3 configuration on
  the top-tier of a multi-module project.
  The goals I am running are:
 
  Surefire: surefire-report:report
  Cobertura: cobertura:cobertura
 
  Is it possible to run the both reports in the same run *withou*t *running
  the tests twice*? I have tried two approaches:
 
  1) mvn both goals
  2) Site: site:site
 
  However, because site:site ran for too long (more than 2 minutes, vs a 30
  second surefire-report), I inspected its output, and found out it was
  running each test twice (eg, I found two string matches of Running
  org.iwrs.web.IndexActionTest).
 
  To reduce total goal time, can *tests run once and produce surefire and
  cobertura reports*?
 
  Thank you,
 
  Miguel Almeida
 
  [1]
  plugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-site-plugin/artifactId
 version3.0-beta-3/version
 configuration
 reportPlugins
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 version2.7/version
 /plugin
 plugin
 groupIdorg.apache.maven.plugins/groupId
 
  artifactIdmaven-surefire-report-plugin/artifactId
 version2.6/version
 /plugin
 plugin
 groupIdorg.codehaus.mojo/groupId
 
  artifactIdcobertura-maven-plugin/artifactId
 configuration
 instrumentation
 excludes
 
  excludecom/work/**/*Fake*.class/exclude
 /excludes
 /instrumentation
 /configuration
 /plugin
 /reportPlugins
 /configuration
 /plugin
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Can cobertura and surefire-report plugins be run without running the tests twice?

[Stephen Connolly]

In my experience you have:
  * a 40% chance of the failure being a bad test
  * a 40% chance of the failure being a bug in your production code
  * a 20% chance of the failure being a side-effect of instrumentation
which invalidates the test

If you and all the developers in your team cannot explain what will be
output by the example code on page 33 of Java Concurrency In Practice
( http://jcip.net/listings/NoVisibility.java ) and why then please
please Run the Damn Tests Twice

If you can explain, then you will run the damn tests twice anyway.

The above example is just one way where the JVM spec can confuse you...

There are others which have nothing to do with concurrency, but I
don't have handy links to them.

Just Run The Damn Tests Twice(TM)

-Stephen

On 27 September 2011 12:14, Miguel Almeida migueldealme...@gmail.com wrote:
 Thank you for pointing out to that discussion.  Even though I don't agree
 completely - if running the coverage tool Cobertura changes the status of
 your tests, I'd say that in most likelihood the problem should be cobertura
 and not your code or your test - I might live with running the cobertura
 goal separately and even move it to the CI system: it delays quick feedback
 to the developer locally anyway.

 Miguel Almeida

 On Mon, Sep 26, 2011 at 4:08 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 http://maven.40175.n5.nabble.com/Cobertura-and-Surefire-td3338334.html




 On 26 September 2011 15:46, Miguel Almeida migueldealme...@gmail.com
 wrote:
  I am using the cobertura plugin to create test coverage reports, and
  surefire-report for test reports. See [1] for my maven 3 configuration on
  the top-tier of a multi-module project.
  The goals I am running are:
 
  Surefire: surefire-report:report
  Cobertura: cobertura:cobertura
 
  Is it possible to run the both reports in the same run *withou*t *running
  the tests twice*? I have tried two approaches:
 
  1) mvn both goals
  2) Site: site:site
 
  However, because site:site ran for too long (more than 2 minutes, vs a 30
  second surefire-report), I inspected its output, and found out it was
  running each test twice (eg, I found two string matches of Running
  org.iwrs.web.IndexActionTest).
 
  To reduce total goal time, can *tests run once and produce surefire and
  cobertura reports*?
 
  Thank you,
 
  Miguel Almeida
 
  [1]
  plugins
             plugin
                 groupIdorg.apache.maven.plugins/groupId
                 artifactIdmaven-site-plugin/artifactId
                 version3.0-beta-3/version
                 configuration
                     reportPlugins
                         plugin
                             groupIdorg.apache.maven.plugins/groupId
                             artifactIdmaven-javadoc-plugin/artifactId
                             version2.7/version
                         /plugin
                         plugin
                             groupIdorg.apache.maven.plugins/groupId
 
  artifactIdmaven-surefire-report-plugin/artifactId
                             version2.6/version
                         /plugin
                         plugin
                             groupIdorg.codehaus.mojo/groupId
 
  artifactIdcobertura-maven-plugin/artifactId
                             configuration
                                 instrumentation
                                     excludes
 
  excludecom/work/**/*Fake*.class/exclude
                                     /excludes
                                 /instrumentation
                             /configuration
                         /plugin
                     /reportPlugins
                 /configuration
             /plugin
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Can cobertura and surefire-report plugins be run without running the tests twice?

[Miguel Almeida]

I am using the cobertura plugin to create test coverage reports, and
surefire-report for test reports. See [1] for my maven 3 configuration on
the top-tier of a multi-module project.
The goals I am running are:

Surefire: surefire-report:report
Cobertura: cobertura:cobertura

Is it possible to run the both reports in the same run *withou*t *running
the tests twice*? I have tried two approaches:

1) mvn both goals
2) Site: site:site

However, because site:site ran for too long (more than 2 minutes, vs a 30
second surefire-report), I inspected its output, and found out it was
running each test twice (eg, I found two string matches of Running
org.iwrs.web.IndexActionTest).

To reduce total goal time, can *tests run once and produce surefire and
cobertura reports*?

Thank you,

Miguel Almeida

[1]
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version3.0-beta-3/version
configuration
reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
version2.7/version
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId

artifactIdmaven-surefire-report-plugin/artifactId
version2.6/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
instrumentation
excludes

excludecom/work/**/*Fake*.class/exclude
/excludes
/instrumentation
/configuration
/plugin
/reportPlugins
/configuration
/plugin

Re: Can cobertura and surefire-report plugins be run without running the tests twice?

[Stephen Connolly]

http://maven.40175.n5.nabble.com/Cobertura-and-Surefire-td3338334.html

On 26 September 2011 15:46, Miguel Almeida migueldealme...@gmail.com wrote:
 I am using the cobertura plugin to create test coverage reports, and
 surefire-report for test reports. See [1] for my maven 3 configuration on
 the top-tier of a multi-module project.
 The goals I am running are:

 Surefire: surefire-report:report
 Cobertura: cobertura:cobertura

 Is it possible to run the both reports in the same run *withou*t *running
 the tests twice*? I have tried two approaches:

 1) mvn both goals
 2) Site: site:site

 However, because site:site ran for too long (more than 2 minutes, vs a 30
 second surefire-report), I inspected its output, and found out it was
 running each test twice (eg, I found two string matches of Running
 org.iwrs.web.IndexActionTest).

 To reduce total goal time, can *tests run once and produce surefire and
 cobertura reports*?

 Thank you,

 Miguel Almeida

 [1]
 plugins
            plugin
                groupIdorg.apache.maven.plugins/groupId
                artifactIdmaven-site-plugin/artifactId
                version3.0-beta-3/version
                configuration
                    reportPlugins
                        plugin
                            groupIdorg.apache.maven.plugins/groupId
                            artifactIdmaven-javadoc-plugin/artifactId
                            version2.7/version
                        /plugin
                        plugin
                            groupIdorg.apache.maven.plugins/groupId

 artifactIdmaven-surefire-report-plugin/artifactId
                            version2.6/version
                        /plugin
                        plugin
                            groupIdorg.codehaus.mojo/groupId
                            artifactIdcobertura-maven-plugin/artifactId
                            configuration
                                instrumentation
                                    excludes

 excludecom/work/**/*Fake*.class/exclude
                                    /excludes
                                /instrumentation
                            /configuration
                        /plugin
                    /reportPlugins
                /configuration
            /plugin


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

ParseException in cobertura with some generics

[IT/R2A]

Hi,

I am using the cobertura-maven-plugin (version 2.4) for code test coverage.
The compile works. But I get an error when I try to generate the site.

Error:
[DEBUG] Calling NCSSExecuter with encoding : UTF-8 ParseException in 
classname.java Encountered at line 83, column 14.
Was expecting one of:
assert ...
IDENTIFIER ...
; ...
= ...
++ ...
-- ...
+= ...
-= ...
*= ...
/= ...
= ...
|= ...
^= ...
%= ...
= ...
= ...
= ...

Here is the line that the error is coming from:
this.SomeDataType foo( pValue );

Has anybody have had the same problem or possible solutions for this problem?

I saw, that I can exclude or ignore some files, but that is probably not the 
best way to handle this error :)

Stacktrace:

[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error during page 
generation
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at 
org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:173)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
at 
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:974)
at 
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:905)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page 
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at 
hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 28 more
Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error 
rendering Maven report: Error while JavaNCSS was executing
at 
org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330)
at 
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134)
at 
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118)
... 31 more
Caused by: org.apache.maven.reporting.MavenReportException: Error while 
JavaNCSS was executing
at 
org.codehaus.mojo.javancss.NcssExecuter.execute(NcssExecuter.java:112)
at 
org.codehaus.mojo.javancss.NcssReportMojo.generateSingleReport(NcssReportMojo.java:264)
at 
org.codehaus.mojo.javancss.NcssReportMojo.executeReport(NcssReportMojo.java:180)
at 
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98

Re: ParseException in cobertura with some generics

[Wayne Fay]

 Error:
 [DEBUG] Calling NCSSExecuter with encoding : UTF-8 ParseException in 
 classname.java Encountered at line 83, column 14.
 Caused by: javancss.parser.ParseException: Encountered at line 
 774, column 14.
 Was expecting one of:

        at 
 javancss.parser.JavaParser.generateParseException(JavaParser.java:10248)

Sure looks like a javancss error, and cobertura is using javancss
under the covers. I'd go ask whoever produces that tool (javancss)
about the error you're getting. Perhaps there's a new version out that
properly handles this grammar.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] cobertura-maven-plugin 2.5.1 Release

[Benson Margulies]

Hi,

The Mojo team is pleased to announce the release of the
cobertura-maven-plugin version 2.5.1.

The cobertura maven plugin plugs cobertura into maven.

http://mojo.codehaus.org/cobertura-maven-plugin/

To get this update, simply specify the version in your project's
plugin configuration:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.5.1/version
/plugin



Release Notes

Release Notes - Maven 2.x Cobertura Plugin - Version 2.5.1


** Bug
* [MCOBERTURA-132] - forkMode is ignored when generating cobertura
reports using Maven 3
* [MCOBERTURA-145] - Regression: report will not be rendered on
invocation of mvn clean install site for a multi module project.

** Improvement
* [MCOBERTURA-144] - The JIRA report should only list those issues
fixed in the current release



Enjoy,

The Mojo team.

benson margulies

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Aggregating cobertura reports in a multi module build with Maven 3.0.3

[Mirko Friedenhagen]

Hello,

I am trying to use cobertura 2.5 with Maven 3.0.3 and want it's
reports to be aggregated in a multi-module build What am I
doing wrong?

Looking at 
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/src/main/java/org/codehaus/mojo/cobertura/CoberturaReportMojo.java
it seems to me, that the cobertura goal should be invoked during the
test phase. Right now, when I invoke mvn clean install site IMO this
goal should be invoked automatically. But I do not see the html or xml
report in the modules. The output of mvn clean install site may be
found at http://pastebin.com/MrvWefeV, the source code for this was:
https://github.com/mfriedenhagen/multi-module-sample/commit/d25db3666b4f9388ca0879378b4917a89062323d

Thanks for your answers
A confused Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Aggregating cobertura reports in a multi module build with Maven 3.0.3

[Benson Margulies]

From the integration test, I see this in the top-level pom.

 build
plugins
  plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.5/version
configuration
  aggregatetrue/aggregate
/configuration
  /plugin
/plugins
  /build



On Thu, Apr 21, 2011 at 3:58 PM, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 Hello,

 I am trying to use cobertura 2.5 with Maven 3.0.3 and want it's
 reports to be aggregated in a multi-module build What am I
 doing wrong?

 Looking at 
 http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/src/main/java/org/codehaus/mojo/cobertura/CoberturaReportMojo.java
 it seems to me, that the cobertura goal should be invoked during the
 test phase. Right now, when I invoke mvn clean install site IMO this
 goal should be invoked automatically. But I do not see the html or xml
 report in the modules. The output of mvn clean install site may be
 found at http://pastebin.com/MrvWefeV, the source code for this was:
 https://github.com/mfriedenhagen/multi-module-sample/commit/d25db3666b4f9388ca0879378b4917a89062323d

 Thanks for your answers
 A confused Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Aggregating cobertura reports in a multi module build with Maven 3.0.3

[Mirko Friedenhagen]

I tried this as well (had a look in the integration test). I now put
the report plugins into the reportPlugins-Element as suggested in
https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-NewConfiguration
and enabled aggregation in a seperate section for the corbertura
plugin as well, see:
https://github.com/mfriedenhagen/multi-module-sample/commit/fd784cfdb1d4c7543e298b1bc7d22a7718a234d8,
the output from this may be seen at:
http://pastebin.com/raw.php?i=YE0DcfKk. What is strange IMO:
- generation of the cobertura report is skipped and in the
project-reports.html of the modules I see:
a href=index.html title=Cobertura Test CoverageCobertura Test Coverage/a
So the cobertura/ part seems to be missing.

Regards
Mirko

On Thu, Apr 21, 2011 at 22:20, Benson Margulies bimargul...@gmail.com wrote:
 From the integration test, I see this in the top-level pom.

  build
    plugins
      plugin
        groupIdorg.codehaus.mojo/groupId
        artifactIdcobertura-maven-plugin/artifactId
        version2.5/version
        configuration
          aggregatetrue/aggregate
        /configuration
      /plugin
    /plugins
  /build



 On Thu, Apr 21, 2011 at 3:58 PM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello,

 I am trying to use cobertura 2.5 with Maven 3.0.3 and want it's
 reports to be aggregated in a multi-module build What am I
 doing wrong?

 Looking at 
 http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/src/main/java/org/codehaus/mojo/cobertura/CoberturaReportMojo.java
 it seems to me, that the cobertura goal should be invoked during the
 test phase. Right now, when I invoke mvn clean install site IMO this
 goal should be invoked automatically. But I do not see the html or xml
 report in the modules. The output of mvn clean install site may be
 found at http://pastebin.com/MrvWefeV, the source code for this was:
 https://github.com/mfriedenhagen/multi-module-sample/commit/d25db3666b4f9388ca0879378b4917a89062323d

 Thanks for your answers
 A confused Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org





-- 
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Aggregating cobertura reports in a multi module build with Maven 3.0.3

[Mirko Friedenhagen]

BTW: when invoking mvn clean install cobertura:cobertura site I do
see the aggregated report in the workspace
(http://huschteguzzel.de/hudson/job/test-multimodule/ws/target/site/cobertura/index.html
or 
http://huschteguzzel.de/hudson/job/test-multimodule/ws/core/target/site/cobertura/index.html),
however site will not pick this up correctly.

Regards
Mirko

On Thu, Apr 21, 2011 at 22:38, Mirko Friedenhagen
mfriedenha...@gmail.com wrote:
 I tried this as well (had a look in the integration test). I now put
 the report plugins into the reportPlugins-Element as suggested in
 https://cwiki.apache.org/MAVEN/maven-3x-and-site-plugin.html#Maven3.xandsiteplugin-NewConfiguration
 and enabled aggregation in a seperate section for the corbertura
 plugin as well, see:
 https://github.com/mfriedenhagen/multi-module-sample/commit/fd784cfdb1d4c7543e298b1bc7d22a7718a234d8,
 the output from this may be seen at:
 http://pastebin.com/raw.php?i=YE0DcfKk. What is strange IMO:
 - generation of the cobertura report is skipped and in the
 project-reports.html of the modules I see:
 a href=index.html title=Cobertura Test CoverageCobertura Test 
 Coverage/a
 So the cobertura/ part seems to be missing.

 Regards
 Mirko

 On Thu, Apr 21, 2011 at 22:20, Benson Margulies bimargul...@gmail.com wrote:
 From the integration test, I see this in the top-level pom.

  build
    plugins
      plugin
        groupIdorg.codehaus.mojo/groupId
        artifactIdcobertura-maven-plugin/artifactId
        version2.5/version
        configuration
          aggregatetrue/aggregate
        /configuration
      /plugin
    /plugins
  /build



 On Thu, Apr 21, 2011 at 3:58 PM, Mirko Friedenhagen
 mfriedenha...@gmail.com wrote:
 Hello,

 I am trying to use cobertura 2.5 with Maven 3.0.3 and want it's
 reports to be aggregated in a multi-module build What am I
 doing wrong?

 Looking at 
 http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.5/src/main/java/org/codehaus/mojo/cobertura/CoberturaReportMojo.java
 it seems to me, that the cobertura goal should be invoked during the
 test phase. Right now, when I invoke mvn clean install site IMO this
 goal should be invoked automatically. But I do not see the html or xml
 report in the modules. The output of mvn clean install site may be
 found at http://pastebin.com/MrvWefeV, the source code for this was:
 https://github.com/mfriedenhagen/multi-module-sample/commit/d25db3666b4f9388ca0879378b4917a89062323d

 Thanks for your answers
 A confused Mirko
 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org





 --
 http://illegalstateexception.blogspot.com/
 https://github.com/mfriedenhagen/
 https://bitbucket.org/mfriedenhagen/




-- 
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[ANN] cobertura-maven-plugin 2.5 released

[Benson Margulies]

Hi,

The Mojo team is pleased to announce the release of the
cobertura-maven-plugin version P2.5.

This plugin provides maven integration for the cobertura open source
code coverage tool.

For more information, see http://mojo.codehaus.org/cobertura-maven-plugin/.

To get this update, simply specify the version in your project's
plugin configuration:

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.5/version
/plugin

It may be of particular interest that this release includes support
for aggregation.

Release Notes

 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11226version=16413


Enjoy,

The Mojo team.

Benson Margulies

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [Cobertura] Cobertura Report Not Showing

[Collins, Russell]

Well, if you feel that way, then announcing third party plugins should not be 
allowed on this mailing list as well.


Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Friday, February 25, 2011 8:26 PM
To: Maven Users List
Subject: Re: [Cobertura] Cobertura Report Not Showing

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.
...
groupIdorg.codehaus.mojo/groupId
...
 Please help and update the online documentation.  Thanks.

What exactly do you expect the Maven project to do about your problems
with a third-party (Codehaus Mojo) plugin??

[Disclaimer: I also participate in the Codehaus.]

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.

RE: [Cobertura] Cobertura Report Not Showing

[Collins, Russell]

...and one more thing.  If you are not going to help, please don’t respond.


Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda


-Original Message-
From: Collins, Russell
Sent: Monday, February 28, 2011 8:16 AM
To: 'Maven Users List'
Subject: RE: [Cobertura] Cobertura Report Not Showing

Well, if you feel that way, then announcing third party plugins should not be 
allowed on this mailing list as well.


Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda

-Original Message-
From: Wayne Fay [mailto:wayne...@gmail.com]
Sent: Friday, February 25, 2011 8:26 PM
To: Maven Users List
Subject: Re: [Cobertura] Cobertura Report Not Showing

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.
...
groupIdorg.codehaus.mojo/groupId
...
 Please help and update the online documentation.  Thanks.

What exactly do you expect the Maven project to do about your problems
with a third-party (Codehaus Mojo) plugin??

[Disclaimer: I also participate in the Codehaus.]

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.

Re: [Cobertura] Cobertura Report Not Showing

[Ryan Connolly]

I think what Wayne was trying to say is that there is a separate list for
help with individual plugins.  In this case you may get more specific help
here:  http://mojo.codehaus.org/cobertura-maven-plugin/mail-lists.html




On Mon, Feb 28, 2011 at 9:16 AM, Collins, Russell rcoll...@corelogic.comwrote:

 ...and one more thing.  If you are not going to help, please don’t respond.


 Russell Collins
 Sr. Software Engineer
 CoreLogic Spatial Solutions

 Do or do not, there is no try. - Yoda


 -Original Message-
 From: Collins, Russell
 Sent: Monday, February 28, 2011 8:16 AM
 To: 'Maven Users List'
 Subject: RE: [Cobertura] Cobertura Report Not Showing

 Well, if you feel that way, then announcing third party plugins should not
 be allowed on this mailing list as well.


 Russell Collins
 Sr. Software Engineer
 CoreLogic Spatial Solutions

 Do or do not, there is no try. - Yoda

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, February 25, 2011 8:26 PM
 To: Maven Users List
 Subject: Re: [Cobertura] Cobertura Report Not Showing

  I am not able to get this plugin to work properly.  The online
 documentation is terrible.
 ...
 groupIdorg.codehaus.mojo/groupId
 ...
  Please help and update the online documentation.  Thanks.

 What exactly do you expect the Maven project to do about your problems
 with a third-party (Codehaus Mojo) plugin??

 [Disclaimer: I also participate in the Codehaus.]

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 ***
 This message may contain confidential or proprietary information intended
 only
 for the use of the addressee(s) named above or may contain information that
 is
 legally privileged. If you are not the intended addressee, or the person
 responsible for delivering it to the intended addressee, you are hereby
 notified that reading, disseminating, distributing or copying this message
 is
 strictly prohibited. If you have received this message by mistake, please
 immediately notify us by replying to the message and delete the original
 message and any copies immediately thereafter.

 Thank you.
 

Re: [Cobertura] Cobertura Report Not Showing

[Hilco Wijbenga]

On 25 February 2011 22:58, Collins, Russell rcoll...@corelogic.com wrote:

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.  When I run the plugin, I can get the results from the clean and 
 check goals.  However, it seems as though the cobertura goal isn't even 
 running.  Here is my xml:

 Plugin section
 ...
 plugin
                groupIdorg.codehaus.mojo/groupId
                artifactIdcobertura-maven-plugin/artifactId
                version2.4/version
                executions
                    execution
                        goals
                            goalclean/goal
                            goalcobertura/goal
                            goalcheck/goal
                        /goals
                    /execution
                /executions
            /plugin

 ...

 Report section

 ...
 reporting
        plugins
            plugin
                groupIdorg.codehaus.mojo/groupId
                artifactIdcobertura-maven-plugin/artifactId
                configuration
                    formats
                        formathtml/format
                        formatxml/format
                    /formats
                    outputDirectorytarget/site/cobertura/outputDirectory
                /configuration
            /plugin
        /plugins
      /reporting
 ...

 Once again, the clean and check seem to be functioning but  there is no site 
 created in any format when this is run.  Please help and update the online 
 documentation.  Thanks.

I just have

reporting
  plugins
snip/
plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.4/version
  configuration
formats
  formathtml/format
  formatxml/format
/formats
  /configuration
/plugin
  /plugins
/reporting

And it all works fine. You are running mvn site, right?

Re: [Cobertura] Cobertura Report Not Showing

[Hilco Wijbenga]

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, February 25, 2011 8:26 PM
 To: Maven Users List
 Subject: Re: [Cobertura] Cobertura Report Not Showing

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.
 ...
                groupIdorg.codehaus.mojo/groupId
 ...
 Please help and update the online documentation.  Thanks.

 What exactly do you expect the Maven project to do about your problems
 with a third-party (Codehaus Mojo) plugin??

 -Original Message-
 From: Collins, Russell
 Sent: Monday, February 28, 2011 8:16 AM
 To: 'Maven Users List'
 Subject: RE: [Cobertura] Cobertura Report Not Showing

 Well, if you feel that way, then announcing third party plugins should not be 
 allowed on this mailing list as well.

What *do* you expect the Maven project to do about the documentation
of a third party plugin?

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [Cobertura] Cobertura Report Not Showing

[Collins, Russell]

Thank you.


Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda


-Original Message-
From: Ryan Connolly [mailto:ryn...@gmail.com]
Sent: Monday, February 28, 2011 11:22 AM
To: Maven Users List
Subject: Re: [Cobertura] Cobertura Report Not Showing

I think what Wayne was trying to say is that there is a separate list for
help with individual plugins.  In this case you may get more specific help
here:  http://mojo.codehaus.org/cobertura-maven-plugin/mail-lists.html




On Mon, Feb 28, 2011 at 9:16 AM, Collins, Russell rcoll...@corelogic.comwrote:

 ...and one more thing.  If you are not going to help, please don't respond.


 Russell Collins
 Sr. Software Engineer
 CoreLogic Spatial Solutions

 Do or do not, there is no try. - Yoda


 -Original Message-
 From: Collins, Russell
 Sent: Monday, February 28, 2011 8:16 AM
 To: 'Maven Users List'
 Subject: RE: [Cobertura] Cobertura Report Not Showing

 Well, if you feel that way, then announcing third party plugins should not
 be allowed on this mailing list as well.


 Russell Collins
 Sr. Software Engineer
 CoreLogic Spatial Solutions

 Do or do not, there is no try. - Yoda

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, February 25, 2011 8:26 PM
 To: Maven Users List
 Subject: Re: [Cobertura] Cobertura Report Not Showing

  I am not able to get this plugin to work properly.  The online
 documentation is terrible.
 ...
 groupIdorg.codehaus.mojo/groupId
 ...
  Please help and update the online documentation.  Thanks.

 What exactly do you expect the Maven project to do about your problems
 with a third-party (Codehaus Mojo) plugin??

 [Disclaimer: I also participate in the Codehaus.]

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 ***
 This message may contain confidential or proprietary information intended
 only
 for the use of the addressee(s) named above or may contain information that
 is
 legally privileged. If you are not the intended addressee, or the person
 responsible for delivering it to the intended addressee, you are hereby
 notified that reading, disseminating, distributing or copying this message
 is
 strictly prohibited. If you have received this message by mistake, please
 immediately notify us by replying to the message and delete the original
 message and any copies immediately thereafter.

 Thank you.
 


***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [Cobertura] Cobertura Report Not Showing

[Collins, Russell]

Of course the base maven project is not going to do anything about the third 
party documentation.  However, based on what I have scene, there are a lot of 
questions and answers that are not just base maven.  There are announcements 
about third party tools along with questions that involve third party tools.  
Based on that, I thought that it would be acceptable to ask my questions and 
express to the community that the documentation did not provide enough 
information.


Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda


-Original Message-
From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com]
Sent: Monday, February 28, 2011 11:23 AM
To: Maven Users List
Cc: Collins, Russell
Subject: Re: [Cobertura] Cobertura Report Not Showing

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, February 25, 2011 8:26 PM
 To: Maven Users List
 Subject: Re: [Cobertura] Cobertura Report Not Showing

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.
 ...
groupIdorg.codehaus.mojo/groupId
 ...
 Please help and update the online documentation.  Thanks.

 What exactly do you expect the Maven project to do about your problems
 with a third-party (Codehaus Mojo) plugin??

 -Original Message-
 From: Collins, Russell
 Sent: Monday, February 28, 2011 8:16 AM
 To: 'Maven Users List'
 Subject: RE: [Cobertura] Cobertura Report Not Showing

 Well, if you feel that way, then announcing third party plugins should not be 
 allowed on this mailing list as well.

What *do* you expect the Maven project to do about the documentation
of a third party plugin?

***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.

RE: [Cobertura] Cobertura Report Not Showing

[Collins, Russell]

Thank you for your help. I am running mvn site.  I have also found a solution 
to my issue.  Basically, I run the plugin during the package phase.  This 
link is where I got my information

http://hedemark.net/blog/?cat=4



Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions

Do or do not, there is no try. - Yoda


-Original Message-
From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com]
Sent: Monday, February 28, 2011 11:23 AM
To: Maven Users List
Cc: Collins, Russell
Subject: Re: [Cobertura] Cobertura Report Not Showing

On 25 February 2011 22:58, Collins, Russell rcoll...@corelogic.com wrote:

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.  When I run the plugin, I can get the results from the clean and 
 check goals.  However, it seems as though the cobertura goal isn't even 
 running.  Here is my xml:

 Plugin section
 ...
 plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.4/version
executions
execution
goals
goalclean/goal
goalcobertura/goal
goalcheck/goal
/goals
/execution
/executions
/plugin

 ...

 Report section

 ...
 reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
formats
formathtml/format
formatxml/format
/formats
outputDirectorytarget/site/cobertura/outputDirectory
/configuration
/plugin
/plugins
  /reporting
 ...

 Once again, the clean and check seem to be functioning but  there is no site 
 created in any format when this is run.  Please help and update the online 
 documentation.  Thanks.

I just have

reporting
  plugins
snip/
plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.4/version
  configuration
formats
  formathtml/format
  formatxml/format
/formats
  /configuration
/plugin
  /plugins
/reporting

And it all works fine. You are running mvn site, right?

***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.

Re: [Cobertura] Cobertura Report Not Showing

[Wayne Fay]

Of course there are a lot of QA that are not just about the Maven
core and plugins under org.apache.maven.plugins. And it is always
acceptable to ask questions here and hope that maybe someone will be
able to help you.

But it seemed like your email was more of a complaint about poor
documentation that I felt should be addressed to the group responsible
for that specific plugin. You said very explicitly please help and
update the online documentation which sounded like you were expecting
someone on this list to take specific action based on your email.

There is not much anyone on this list can do about poor docs for
plugins not under o.a.m.p. If you really feel the documentation is
lacking, the most pragmatic route is not to merely complain about it
on an email list but rather to actually post a bug/issue in the
relevant project's bug tracker. Otherwise they are probably thinking
our documentation must be great, no one ever complains about it!

Thanks to Ryan and Hilco for helping me express my thoughts more clearly. ;-)

Wayne

On Mon, Feb 28, 2011 at 11:30 AM, Collins, Russell
rcoll...@corelogic.com wrote:
 Of course the base maven project is not going to do anything about the third 
 party documentation.  However, based on what I have scene, there are a lot of 
 questions and answers that are not just base maven.  There are announcements 
 about third party tools along with questions that involve third party tools.  
 Based on that, I thought that it would be acceptable to ask my questions and 
 express to the community that the documentation did not provide enough 
 information.


 Russell Collins
 Sr. Software Engineer
 CoreLogic Spatial Solutions

 Do or do not, there is no try. - Yoda


 -Original Message-
 From: Hilco Wijbenga [mailto:hilco.wijbe...@gmail.com]
 Sent: Monday, February 28, 2011 11:23 AM
 To: Maven Users List
 Cc: Collins, Russell
 Subject: Re: [Cobertura] Cobertura Report Not Showing

 -Original Message-
 From: Wayne Fay [mailto:wayne...@gmail.com]
 Sent: Friday, February 25, 2011 8:26 PM
 To: Maven Users List
 Subject: Re: [Cobertura] Cobertura Report Not Showing

 I am not able to get this plugin to work properly.  The online 
 documentation is terrible.
 ...
                groupIdorg.codehaus.mojo/groupId
 ...
 Please help and update the online documentation.  Thanks.

 What exactly do you expect the Maven project to do about your problems
 with a third-party (Codehaus Mojo) plugin??

 -Original Message-
 From: Collins, Russell
 Sent: Monday, February 28, 2011 8:16 AM
 To: 'Maven Users List'
 Subject: RE: [Cobertura] Cobertura Report Not Showing

 Well, if you feel that way, then announcing third party plugins should not 
 be allowed on this mailing list as well.

 What *do* you expect the Maven project to do about the documentation
 of a third party plugin?

 ***
 This message may contain confidential or proprietary information intended only
 for the use of the addressee(s) named above or may contain information that is
 legally privileged. If you are not the intended addressee, or the person
 responsible for delivering it to the intended addressee, you are hereby
 notified that reading, disseminating, distributing or copying this message is
 strictly prohibited. If you have received this message by mistake, please
 immediately notify us by replying to the message and delete the original
 message and any copies immediately thereafter.

 Thank you.
 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[Cobertura] Cobertura Report Not Showing

[Collins, Russell]

I am not able to get this plugin to work properly.  The online documentation is 
terrible.  When I run the plugin, I can get the results from the clean and 
check goals.  However, it seems as though the cobertura goal isn't even 
running.  Here is my xml:

Plugin section
...
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version2.4/version
executions
execution
goals
goalclean/goal
goalcobertura/goal
goalcheck/goal
/goals
/execution
/executions
/plugin

...

Report section

...
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
formats
formathtml/format
formatxml/format
/formats
outputDirectorytarget/site/cobertura/outputDirectory
/configuration
/plugin
/plugins
  /reporting
...

Once again, the clean and check seem to be functioning but  there is no site 
created in any format when this is run.  Please help and update the online 
documentation.  Thanks.



Russell Collins
Sr. Software Engineer
CoreLogic Spatial Solutions



Do or do not, there is no try. - Yoda



***
This message may contain confidential or proprietary information intended only
for the use of the addressee(s) named above or may contain information that is
legally privileged. If you are not the intended addressee, or the person
responsible for delivering it to the intended addressee, you are hereby
notified that reading, disseminating, distributing or copying this message is
strictly prohibited. If you have received this message by mistake, please
immediately notify us by replying to the message and delete the original
message and any copies immediately thereafter.

Thank you.

Re: [Cobertura] Cobertura Report Not Showing

[Wayne Fay]

 I am not able to get this plugin to work properly.  The online documentation 
 is terrible.
...
                groupIdorg.codehaus.mojo/groupId
...
 Please help and update the online documentation.  Thanks.

What exactly do you expect the Maven project to do about your problems
with a third-party (Codehaus Mojo) plugin??

[Disclaimer: I also participate in the Codehaus.]

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stefan Schulze]

Jeff Jensen wrote:
  Sounds nice, but this doesn't meet my requirement, that the 
  tests with coverage-checks (and only one time, not twice)
  should run, when the developers do mvn test.
 There is no acceptable solution to this requirement.  Many 
 of us would like to not run them twice, and in actuality 
 running them twice is not a problem for things like site gen.

Thank you for this information, that it's currently simply not possible.

I think that's a shortcoming of cobertura-maven-plugin. It should be possible 
to overwrite the default surefire-configuration within the 
cobertura-configuration.
But for now I have to look for another way (thank you and the others for the 
suggestions)

  we unfortunately don't use a
  regular CI-server but a bunch of shellscripts and cron-jobs. 
  So it's not as trivial as with Hudson (Jenkins?) to use this 
  kind of build-pipeline.
 Looks like it is time to invest a couple of days and set it 
 up!  Your work life will be easier and maintenance cheaper.

I completely aggree with you and I'd love to replace the scripts by a neat 
Hudson-installation. But the only way to do this (or the only way I can 
imagine) is to create a buildjob which simply calls our current 
master-buildscript. But I don't think I improved anything by doing this.
We can't use the most of hudson out of the box. Even the updating of the 
working-copy is not trivial: not only that we use CM Synergy (little support 
for it in Hudson and no public Java-API), but we need a combination of CM 
Synergy and Change Synergy to calculate the tasks to update.
I would really appreciate to migrate the build of the last 100 modules to Maven 
without the need of specialized builds for each target-stage, using a 
mainstream SCM-tool and so on... Unfortunately I think the client wouldn't 
pay for this work (not to forget the QA of the whole application).
But I think, I go off on a tangent.
-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!   
Jetzt informieren: http://www.gmx.net/de/go/freephone

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stefan Schulze]

Stephen Connolly wrote:
 Because people who have not read and understood concurrency in
 practice often do not understand how the synchronization points affect
 jvm sequencing, people often wrongly suspect that result of
 instrumented and non-instrumented code is the same.

I'm not sure, why caring about concurrency is important in this context. I'm 
not using Maven 3 (so no concurrent builds) and I'm not using concurrent tests 
with JUnit.
But it's quite plain to me it is possible, that instrumented code behaves 
different to uninstrumented code, so testing the instrumented code can pass the 
tests while uninstrumented fail. (i.e. because of attributes added by 
instrumentation, which are unexpected when working with reflection on these 
attributes)

But I think it doesn't happen on a regular basis, that the instrumented code 
pass or fails the tests, where the uninstrumented doesn't. But sadly it's more 
regular in our team, that the Cobertura-step fails (not because failing tests 
but because of too low coverage).


Wayne Fay wrote:
 Perhaps bind something to your scm commit hook so the code 
 simply can't make it into your SCM tool without meeting 
 certain standards for coverage?

That would mean, that during the commit we should run all the tests? I'm not 
sure, I want the commit to last about two minutes.
Beside this, we have to use Synergy/CM as SCM tool, which is not capable of 
pre-commit-hooks (as far as I know).

Hilco Wijbenga wrote:
 A normal unit test should run once, more is just a waste of 
 time. The fact that Maven will run unit tests multiple times 
 is a bug that we apparently have to live with. It is not a feature.
 
 If this bug were fixed and you still wanted to run your unit 
 tests twice then you could configure that quite easily in your POM.
 Everybody happy

I don't really like that Maven needs to run tests twice (or more often), too. 
But I see it is neccessary regarding Cobertura, because -- as stated to Stephen 
-- it can't be guaranteed, that the instrumented code behaves the same as the 
uninstrumented. Because of this it is not sufficient to run the tests only on 
the instrumented code.
So this is not a bug in Maven but a problem with Cobertura.
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stephen Connolly]

On 13 January 2011 09:50, Stefan Schulze algr...@gmx.de wrote:
 Stephen Connolly wrote:
 Because people who have not read and understood concurrency in
 practice often do not understand how the synchronization points affect
 jvm sequencing, people often wrongly suspect that result of
 instrumented and non-instrumented code is the same.

 I'm not sure, why caring about concurrency is important in this context. I'm 
 not using Maven 3 (so no concurrent builds) and I'm not using concurrent 
 tests with JUnit.

Between synchronization points, the JVM is allowed to re-order
operations as long as the end result remains the same.

Cobertura puts a synchronization point in between every line and branch point.

Thus the re-ordering of lines cannot take place any more.

Start up a JVM and have a look at how many threads are running

Still think you are in a single threaded world?

Also some simple libraries use threads behind your back... and even
the Java Runtime Libraries do that too...

Still think you don't have to know/worry about concurrency?

I shall repeat...

We had some appears to be simple single threaded code that we were
testing with a simple test case.  The tests were only being run
instrumented... the tests were passing the bug was there... seen
in production system by big customer... in the end of the day, this
was identified as the original author not understanding about the
JVM's contract w.r.t. re-ordering operations in-between
synchronization points and the fact that using cobertura introduced a
synchronization point at every line so that the code as written could
only work when instrumented.

Run the damn tests at least twice. (I'd like to say run them on
multiple JVMs too but Oracle seems intent on merging all the JVMs into
openjdk)

-Stephen

 But it's quite plain to me it is possible, that instrumented code behaves 
 different to uninstrumented code, so testing the instrumented code can pass 
 the tests while uninstrumented fail. (i.e. because of attributes added by 
 instrumentation, which are unexpected when working with reflection on these 
 attributes)

 But I think it doesn't happen on a regular basis, that the instrumented code 
 pass or fails the tests, where the uninstrumented doesn't. But sadly it's 
 more regular in our team, that the Cobertura-step fails (not because failing 
 tests but because of too low coverage).


It happens when you least expect it.


 Wayne Fay wrote:
 Perhaps bind something to your scm commit hook so the code
 simply can't make it into your SCM tool without meeting
 certain standards for coverage?

 That would mean, that during the commit we should run all the tests? I'm not 
 sure, I want the commit to last about two minutes.
 Beside this, we have to use Synergy/CM as SCM tool, which is not capable of 
 pre-commit-hooks (as far as I know).

 Hilco Wijbenga wrote:
 A normal unit test should run once, more is just a waste of
 time. The fact that Maven will run unit tests multiple times
 is a bug that we apparently have to live with. It is not a feature.

 If this bug were fixed and you still wanted to run your unit
 tests twice then you could configure that quite easily in your POM.
 Everybody happy

 I don't really like that Maven needs to run tests twice (or more often), too. 
 But I see it is neccessary regarding Cobertura, because -- as stated to 
 Stephen -- it can't be guaranteed, that the instrumented code behaves the 
 same as the uninstrumented. Because of this it is not sufficient to run the 
 tests only on the instrumented code.
 So this is not a bug in Maven but a problem with Cobertura.
 --
 GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
 gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stefan Schulze]

Stephen Connolly wrote:
 [...]
 Run the damn tests at least twice. 

Ok, I see your point. But I never tried to run the tests only instrumented. I 
just want to execute the more-likely-failing tests earlier in the lifecycle and 
the not-so-likely-failing tests later. 
So of course I want to execute both uninstrumented _and_ instrumented tests.
-- 
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stevo Slavić]

IMO solution is simple - discipline your developers to run verify
before commiting. CI should help you determine whom to blame when
build is broken and then you can apply disciplinary meassures.

Regards,
Stevo.

On Thu, Jan 13, 2011 at 11:24 AM, Stefan Schulze algr...@gmx.de wrote:
 Stephen Connolly wrote:
 [...]
 Run the damn tests at least twice.

 Ok, I see your point. But I never tried to run the tests only instrumented. I 
 just want to execute the more-likely-failing tests earlier in the lifecycle 
 and the not-so-likely-failing tests later.
 So of course I want to execute both uninstrumented _and_ instrumented tests.
 --
 Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
 Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Jeff Jensen]

Perhaps a different CI job structuring?  This has worked well for me at many
customers: Have a CI job for only compile and unit tests - this maintains
the most important very fast turnaround.  Have a second CI job for (longer
running) IT tests that only runs with success of the first.  Have a third
job for coverage, standalone or as part of a full system site gen or using
Sonar or other...


On Thu, Jan 13, 2011 at 5:14 AM, Stevo Slavić ssla...@gmail.com wrote:

 IMO solution is simple - discipline your developers to run verify
 before commiting. CI should help you determine whom to blame when
 build is broken and then you can apply disciplinary meassures.

 Regards,
 Stevo.

 On Thu, Jan 13, 2011 at 11:24 AM, Stefan Schulze algr...@gmx.de wrote:
  Stephen Connolly wrote:
  [...]
  Run the damn tests at least twice.
 
  Ok, I see your point. But I never tried to run the tests only
 instrumented. I just want to execute the more-likely-failing tests earlier
 in the lifecycle and the not-so-likely-failing tests later.
  So of course I want to execute both uninstrumented _and_ instrumented
 tests.
  --
  Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
  Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stefan Schulze]

Jeff Jensen wrote:
 Perhaps a different CI job structuring?  This has worked well for me 
 at many
 customers: Have a CI job for only compile and unit tests - this 
 maintains the most important very fast turnaround.  Have a second CI 
 job for (longer
 running) IT tests that only runs with success of the first.  
 Have a third job for coverage, standalone or as part of a full system 
 site gen or using Sonar or other...

Sounds nice, but this doesn't meet my requirement, that the tests with 
coverage-checks (and only one time, not twice) should run, when the developers 
do mvn test. We have a quite small difference between coverage-threshold and 
actual coverage, so I think it's important, that the developers check their 
coverage during development, so they can react early. 

Another problem to your solution is, that we unfortunately don't use a regular 
CI-server but a bunch of shellscripts and cron-jobs. So it's not as trivial as 
with Hudson (Jenkins?) to use this kind of build-pipeline.
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AW: Cobertura and Surefire

[Schulze, Stefan (EXTERN: CKC)]

Jeff Jensen wrote:
 Perhaps a different CI job structuring?  This has worked well 
 for me at many
 customers: Have a CI job for only compile and unit tests - 
 this maintains the most important very fast turnaround.  Have 
 a second CI job for (longer
 running) IT tests that only runs with success of the first.  
 Have a third job for coverage, standalone or as part of a 
 full system site gen or using Sonar or other...

Sounds nice, but this doesn't meet my requirement, that the tests with
coverage-checks (and only one time, not twice) should run, when the
developers do mvn test. We have a quite small difference between
coverage-threshold and actual coverage, so I think it's important, that
the developers check their coverage during development, so they can
react early. 

Another problem to your solution is, that we unfortunately don't use a
regular CI-server but a bunch of shellscripts and cron-jobs. So it's not
as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline.



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Wayne Fay]

 Sounds nice, but this doesn't meet my requirement, that the tests with
 coverage-checks (and only one time, not twice) should run, when the developers
 do mvn test.

It sounds like Maven cannot, for whatever reason, meet your requirement.

 We have a quite small difference between coverage-threshold
 and actual coverage, so I think it's important, that the developers check 
 their
 coverage during development, so they can react early.

It seems like you are only running into this problem because your
coverage is running arbitrarily close to the 80% cutoff that you
defined for test coverage. Perhaps you should instead focus some
energies on bumping your test coverage a lot so you are not so close
to the cutoff (so people aren't casually bumping into it so
regularly), or knock the cutoff down to 75% or so to give some
breathing room?

 Another problem to your solution is, that we unfortunately don't use a regular
 CI-server but a bunch of shellscripts and cron-jobs. So it's not as trivial 
 as with
 Hudson (Jenkins?) to use this kind of build-pipeline.

Why can't you set up a more formal CI server like Hudson? This is
solution proposed by Jeff is a reasonable one and I know this same
strategy is used by a lot of groups doing CI.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Jeff Jensen]

On Thu, Jan 13, 2011 at 9:01 AM, Schulze, Stefan (EXTERN: CKC) 
extern.stefan.schul...@volkswagen.de wrote:

 Jeff Jensen wrote:
  Perhaps a different CI job structuring?  This has worked well
  for me at many
  customers: Have a CI job for only compile and unit tests -
  this maintains the most important very fast turnaround.  Have
  a second CI job for (longer
  running) IT tests that only runs with success of the first.
  Have a third job for coverage, standalone or as part of a
  full system site gen or using Sonar or other...

 Sounds nice, but this doesn't meet my requirement, that the tests with
 coverage-checks (and only one time, not twice) should run, when the
 developers do mvn test.


There is no acceptable solution to this requirement.  Many of us would
like to not run them twice, and in actuality running them twice is not a
problem for things like site gen.

However, my thinking is to separate the two runs anyway, as coverage is not
needed with each local build.
Run mvn test until the tests all pass and the developer thinks there is
reasonable coverage, then run mvn cobertura:cobertura and view the
results.  I think running coverage all the time is not necessary until ready
to inspect it, particularly when I know I have a lots of work to do on the
story/feature; coverage is irrelevant at the start with full TDD (tests
exist, no code exists, compile errors exist) and until I am ready to see the
needed additional cases.  That's for me; YMMV! :-)



 We have a quite small difference between
 coverage-threshold and actual coverage, so I think it's important, that
 the developers check their coverage during development, so they can
 react early.


What IDE is in use?  If Eclipse, consider using eCobertura, a Cobertura
Eclipse plugin, to run the tests in Eclipse and visually see the coverage as
needed.



 Another problem to your solution is, that


Actually, it is a problem with your environment/practices, not with the
solution!  ;-)



 we unfortunately don't use a

regular CI-server but a bunch of shellscripts and cron-jobs. So it's not
 as trivial as with Hudson (Jenkins?) to use this kind of build-pipeline.


Looks like it is time to invest a couple of days and set it up!  Your work
life will be easier and maintenance cheaper.

Cobertura and Surefire

[Stefan Schulze]

Hi,

In our project, the tests take some time - more than the developers are willing 
to execute twice (Surefire and Cobertura) over and over again.
First I bound Cobertura to verify-phase, but because the developers only run 
test to run the tests only once, they never go through the coverage-checks 
and the build on the buildserver breaks regularly because of too less coverage.

Because usually the result of instrumented and non-instrumented code is the 
same, I would like to bind Cobertura on the test-phase and Surefire on the 
verify-phase. But I can't get it work. Maven always executes either both 
plugins in the test-phase or successfully skips Surefire but effectivly skips 
Cobertura, too, because of skipped Surefire.

Currently (both are skipped) I tried to use the following plugin-configuration:
plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.4/version
  configuration
instrumentation
  excludes
exclude**/*Exception.class/exclude
  /excludes
/instrumentation
check
  totalLineRate80/totalLineRate
  haltOnFailuretrue/haltOnFailure
/check
  /configuration
  executions
execution
  phasetest/phase
  goals
goalclean/goal
goalcheck/goal
  /goals
/execution
  /executions
/plugin
plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-surefire-plugin/artifactId
  configuration
skiptrue/skip
  /configuration
  executions
execution
  phaseverify/phase
  goals
goaltest/goal
  /goals
  configuration
skipfalse/skip
  /configuration
/execution
  /executions
/plugin

Does anybody know how to configure this?
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stephen Connolly]

Because people who have not read and understood concurrency in
practice often do not understand how the synchronization points affect
jvm sequencing, people often wrongly suspect that result of
instrumented and non-instrumented code is the same.

I have had bugs which were not caught by unit tests because:
1. The test passed when the code was not instrumented and failed when
the code was instrumented
2. The test failed when the code was not instrumented and passed when
the code was instrumented

As a result of my experiences I will not help you

-Stephen

On 12 January 2011 15:29, Stefan Schulze algr...@gmx.de wrote:
 Hi,

 In our project, the tests take some time - more than the developers are 
 willing to execute twice (Surefire and Cobertura) over and over again.
 First I bound Cobertura to verify-phase, but because the developers only run 
 test to run the tests only once, they never go through the coverage-checks 
 and the build on the buildserver breaks regularly because of too less 
 coverage.

 Because usually the result of instrumented and non-instrumented code is the 
 same, I would like to bind Cobertura on the test-phase and Surefire on the 
 verify-phase. But I can't get it work. Maven always executes either both 
 plugins in the test-phase or successfully skips Surefire but effectivly skips 
 Cobertura, too, because of skipped Surefire.

 Currently (both are skipped) I tried to use the following 
 plugin-configuration:
 plugin
  groupIdorg.codehaus.mojo/groupId
  artifactIdcobertura-maven-plugin/artifactId
  version2.4/version
  configuration
    instrumentation
      excludes
        exclude**/*Exception.class/exclude
      /excludes
    /instrumentation
    check
      totalLineRate80/totalLineRate
      haltOnFailuretrue/haltOnFailure
    /check
  /configuration
  executions
    execution
      phasetest/phase
      goals
        goalclean/goal
        goalcheck/goal
      /goals
    /execution
  /executions
 /plugin
 plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-surefire-plugin/artifactId
  configuration
    skiptrue/skip
  /configuration
  executions
    execution
      phaseverify/phase
      goals
        goaltest/goal
      /goals
      configuration
        skipfalse/skip
      /configuration
    /execution
  /executions
 /plugin

 Does anybody know how to configure this?
 --
 GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
 gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Wayne Fay]

 First I bound Cobertura to verify-phase, but because the developers only run 
 test
 to run the tests only once, they never go through the coverage-checks and the
 build on the buildserver breaks regularly because of too less coverage.

Perhaps bind something to your scm commit hook so the code simply
can't make it into your SCM tool without meeting certain standards for
coverage?

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Hilco Wijbenga]

On 12 January 2011 08:12, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 Because people who have not read and understood concurrency in
 practice often do not understand how the synchronization points affect
 jvm sequencing, people often wrongly suspect that result of
 instrumented and non-instrumented code is the same.

 I have had bugs which were not caught by unit tests because:
 1. The test passed when the code was not instrumented and failed when
 the code was instrumented
 2. The test failed when the code was not instrumented and passed when
 the code was instrumented

This is just silly. If you want to test your concurrent code then
write specific tests for it.

What you are doing is changing the environment (a tiny bit) and hoping
that you will find something. If that is your strategy then make a big
change to your environment and run your tests in really different
environments: IDE vs CLI, Windows vs Linux, desktop vs build server,
etcetera.

A normal unit test should run once, more is just a waste of time. The
fact that Maven will run unit tests multiple times is a bug that we
apparently have to live with. It is not a feature.

If this bug were fixed and you still wanted to run your unit tests
twice then you could configure that quite easily in your POM.
Everybody happy.

 As a result of my experiences I will not help you

Then why reply? Are you suggesting we now all start replying to
everything so that everyone knows we can not/will not help and why?
:-P

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura and Surefire

[Stephen Connolly]

actually these were tests of code that the developers thought not to include
threading or concurrency

I've been badly bitten by running the tests only once. they are unit tests,
they should be fast enough to run them twice.

and you should run them more than once and in a random order each time.

now if it's integration tests... whole different storey.

re your other point. I am consyantly amased at the java developers who think
they don't have to know about threading... they all think that running the
tests once with cobertura and having a successful run means that everything
is fine... that is not best practice. maven is about being opinionated
software. maven's opinion is that only by running the tests un instrumented
can you prove the tests pass. if you don't like mavens opinion, you can have
a hard time fighting it. stay on the naven way and run the damn tests twice

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jan 2011 17:39, Hilco Wijbenga hilco.wijbe...@gmail.com wrote:

Re: NoClassDefFoundError when running maven-exec-plugin and Cobertura

[PaulGee]

We had the same problem. Solution was to add cobertura dependency to the
instrumented component. So, just try adding 

 dependency
  groupIdnet.sourceforge.cobertura/groupId
  artifactIdcobertura/artifactId
  version1.9.4.1/version
/dependency

to your pom and try again. Make sure cobertura version is the same as the
one used by your version of cobertura plugin (in our case it was 2.4)


-- 
View this message in context: 
http://maven.40175.n5.nabble.com/NoClassDefFoundError-when-running-maven-exec-plugin-and-Cobertura-tp103455p3268700.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Surefire-Report and Cobertura

[-Kidow-]

Hello,

I've got a question concerning the surefire-report-plugin and the
cobertura-plugin. 

Is it possible to find out which classes have been covered by which
testclasses?

From the surefire-report-plugin I get the information about which testclass
throws a failure and from the cobertura-plugin I get the line-rate and
information about the class itself. I kind of need to know which testclass
referres to which class. Is it by any chance possible?  

thanks in advance 
-kidow-
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/Surefire-Report-and-Cobertura-tp3228229p3228229.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Moving cobertura-profile to parent-pom

[Stefan Schulze]

Hi,

in my current build I have some projects with a common parent-pom.
In the parent-pom I defined the cobertura-plugin in the 
pluginManagement-section to define some common thing: version, some basic 
configuration, binding to phases.
In the most of the child-poms I have an profile (activation on !skipTests) to 
define some detailed configuration (exclusions,check-thresholds).

I think it's not too bad this way, but it bugs me, that I still have duplicate 
parts of the definition (the profile-stuff and activation-definition). Is it 
possible to move the profiles to to parent-pom while giving the child-poms the 
ability to define exclusions and totalLineRates and to disable cobertura 
completely (for this project)? 

Thanks,
  Stefan
-- 
GMX DSL Doppel-Flat ab 19,99 euro;/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

How to skip cobertura report for single module?

[David Hoffer]

I'm using the cobertura-maven-plugin to generate code coverage reports
during site builds, but it always fails on one module of a large
multi-module project/build.  How can I skip the cobertura report for
the one module?  (The problem module is auto generated code so it
doesn't need this anyway.)

Thanks,
-Dave

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

difference in cobertura instrumented tests

[Em DauPhu]

Hi,

I run mvn clean deploy site -U -Pcobertura,andOtherProfiles using the
profile described below.
I use the cobertura plugin version 2.3.

When I launch a job using this goals and options, tests are executed 4
times.
First question, is that correct ? (2 times with and without instrumentation
and 2 times this for deploy and site lifecycles)
Next question, my build reports for each run in order:
- during deploy lifecycle, before instrumentation
Tests run: 835, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 162.928
sec
- during deploy lifecycle, after instrumentation
Tests run: 841, Failures: 664, Errors: 0, Skipped: 20, Time elapsed: 139.084
sec  FAILURE!
- during site lifecycle, before instrumentation
Tests run: 835, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 161.537
sec
- during site lifecycle, after instrumentation
Tests run: 841, Failures: 664, Errors: 0, Skipped: 20, Time elapsed: 140.021
sec  FAILURE!

How can I investigate ? How do I have more tests while executing surefire on
instrumented tests ?

Thank you in advance.

The cobertura profile in super pom:
profile
idcobertura/id
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
configuration
check
branchRate50/branchRate
lineRate50/lineRate
haltOnFailurefalse/haltOnFailure
totalBranchRate50/totalBranchRate
totalLineRate50/totalLineRate
packageLineRate50/packageLineRate
packageBranchRate50/packageBranchRate
/check
formats
formathtml/format
formatxml/format
/formats
/configuration
executions
execution
goals
goalclean/goal
goalcheck/goal
/goals
/execution
/executions
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId
version${version.cobertura.plugin}/version
configuration
formats
formathtml/format
formatxml/format
/formats
/configuration
/plugin
/plugins
/reporting
/profile

[ANN] Cobertura Maven Plugin 2.4 released

[Simon Brandhof]

The Mojo team is pleased to announce the release of the Cobertura Maven
Plugin, version 2.4.

Documentation on the plugin can be found here:
http://mojo.codehaus.org/cobertura-maven-plugin/

Release Notes

** Bug
* [MCOBERTURA-49] - Fails if JRE is not on System Path
* [MCOBERTURA-67] - mvn cobertura:cobertura class loader problem
* [MCOBERTURA-98] - Trivial typos in CommandLineArguments and
CoberturaReportMojo javadocs
* [MCOBERTURA-105] - AbstractCoberturaTestCase hasn't been upgraded to
cobertura 1.9.2

** Improvement
* [MCOBERTURA-113] - Upgrade to cobertura 1.9.3
* [MCOBERTURA-120] - Update to Cobertura 1.9.4.1
* [MCOBERTURA-122] - Upgrade plexus-utils version to 2.0.2

** New Feature
* [MCOBERTURA-85] - Configuration for different report encodings (other
than UTF-8)

** Task
* [MCOBERTURA-111] - Missing url tag in pom.xml


--
Simon Brandhof

Re: Cobertura version 2.3 fails the JUnit test cases

[Stephen Connolly]

This sounds like more of an issue with cobertura than maven.

I would suggest you try asking the cobertura guys/gals.

As a pointer, I'm betting some of your classes do no have their explicit
serialVersionUID defined.  If those classes are used in the EJB remote
calls, then the instrumented versions of the classes will have a different
implicit serialVersionUID's from the non-instrumented ones loaded by the EJB
classloader to handle the remote end receiving the calls... and vice versa,
any results from the EJB remote invocations will have the same issue.

One workaround is to generate serialVersionUID constants for all your
classes that are marked Serializable (which is good practice anyway), that
might get you a step farther, but I suspect that you'll have to follow up
with the Cobertura guys/gals anyway.

-Stephen

P.S.
  If you find the actual solution after talking to the cobertura guys/gals
can you please post the results to this thread so that others may benifit
from your learnings

On 10 April 2010 04:50, aabhijit aabhijit.ma...@gmail.com wrote:



 Actually I am using cobertura maven plug-in version 2.3 with maven version
 2.1.
 In my JUnits I have DB and EJB calls. During the build I use surefire maven
 plugin property “forkMode=always” and with this property the unit test
 cases
 pass properly.  Otherwise Surefire plugin has problem running JUnits and
 they fail.

 Now during the cobertura:cobertura stage the many test cases fail. The DB
 test cases fail at the executing the DB call (remote calls) and while
 running EJB calls I get serialVersionUID mismatch exceptions. I tried
 instrumenting only the classes under the current module as I believe
 instrumentation of the other classes might be giving this SerialVersionUID
 mismatch but no luck.

 This is multimodule maven build with around 70 artifacts being build in
 that
 build. Even with the single module build the cobertura test cases fail.

 Since the test cases fail we are not able to see the code coverage.

 I would be extremely thankful if you guys can help me to locate the
 problem.

 --
 View this message in context:
 http://old.nabble.com/Cobertura-version-2.3-fails-the-JUnit-test-cases-tp28199798p28199798.html
 Sent from the Maven - Users mailing list archive at Nabble.com.


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura version 2.3 fails the JUnit test cases

[Wayne Fay]

 Actually I am using cobertura maven plug-in version 2.3 with maven version
 2.1.

I have no idea if it will help, but try Maven 2.2.1. You should not be
running 2.1, it has issues.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura version 2.3 fails the JUnit test cases

[Garin Yan]

It seems that Maven 2.1 has many issues? So many problem in the mailing list
is occurred in Maven 2.1.

On Sat, Apr 10, 2010 at 11:03 PM, Wayne Fay wayne...@gmail.com wrote:

  Actually I am using cobertura maven plug-in version 2.3 with maven
 version
  2.1.

 I have no idea if it will help, but try Maven 2.2.1. You should not be
 running 2.1, it has issues.

 Wayne

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-- 
Garin Yan

Software Engineer, International Service
Founder International Co.,Ltd.
Address: Suzhou International Science Park (Phase V)
 328 Xinghu Rd., Suzhou, Jiangsu, P.R.China, 215123
Tel：+86 512 86665500-7063  Fax：+86 512 87183808  Cell:151 0621 9276
yangu...@gmail.com  ||  www.founderinternational.com

Enjoying 20 years of success satisfying global leaders with every IT need --
Founder’s 30,000 employees are committed to helping you succeed.

Re: Cobertura version 2.3 fails the JUnit test cases

[Wayne Fay]

 It seems that Maven 2.1 has many issues? So many problem in the mailing list
 is occurred in Maven 2.1.

Yes, it has problems, and should not be used. As such, you will see
2.2.1 is the primary download on the Maven website, and 2.0.11 is the
archive release.

No one should be running 2.1. If you are, you should move off it asap.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Cobertura version 2.3 fails the JUnit test cases

[aabhijit]

Actually I am using cobertura maven plug-in version 2.3 with maven version
2.1.
In my JUnits I have DB and EJB calls. During the build I use surefire maven
plugin property “forkMode=always” and with this property the unit test cases
pass properly.  Otherwise Surefire plugin has problem running JUnits and
they fail.

Now during the cobertura:cobertura stage the many test cases fail. The DB
test cases fail at the executing the DB call (remote calls) and while
running EJB calls I get serialVersionUID mismatch exceptions. I tried
instrumenting only the classes under the current module as I believe
instrumentation of the other classes might be giving this SerialVersionUID
mismatch but no luck.

This is multimodule maven build with around 70 artifacts being build in that
build. Even with the single module build the cobertura test cases fail.

Since the test cases fail we are not able to see the code coverage.

I would be extremely thankful if you guys can help me to locate the problem.

-- 
View this message in context: 
http://old.nabble.com/Cobertura-version-2.3-fails-the-JUnit-test-cases-tp28199798p28199798.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

AMP packaging type and cobertura

[Julien HENRY]

Hi all,

I have a project that is using Maven Alfresco integration [1] to produce AMP 
artifacts. There is a new packaging type amp. Looking at the source code of 
the plugin the language is java [2].

On cobertura side there is a check [3] to prevent instrumentation in case of 
non java artifact:

ArtifactHandler artifactHandler = project.getArtifact().getArtifactHandler();
   if ( !java.equals( artifactHandler.getLanguage() ) )
   {
   getLog().info(
 Not executing cobertura:instrument as the project is not a Java 
classpath-capable package );
   }

As AMP is supposed to be a java artifact (and that's actually true) I was 
expecting cobertura to perform instrumentation. But in fact it is not:


[INFO] 
[INFO] Building My Project AMP Packaging
[INFO]task-segment: [org.codehaus.mojo:cobertura-maven-plugin:2.3:cobertura]
[INFO] 
[INFO] Preparing cobertura:cobertura
[INFO] [buildnumber:create {execution: default}]
[INFO] Checking for local modifications: skipped.
[INFO] Updating project files from SCM: skipped.
[INFO] Storing buildNumber: 5 at timestamp: 1268819729587
[INFO] [nosnapshot:strip {execution: default}]
[INFO] Storing noSnapshotVersion: 0.1 
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 8 resources to alfresco/module/fr.cirad.contrat
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [cobertura:instrument {execution: default-instrument}]
[INFO] Not executing cobertura:instrument as the project is not a Java 
classpath-capable package
[INFO] [resources:testResources {execution: default-testResources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] [compiler:testCompile {execution: default-testCompile}]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test {execution: default-test}]
[INFO] Surefire report directory: 
/var/lib/hudson/workspace/MyProject/trunk/target/surefire-reports

---
 T E S T S
---
Running fr.myproject.contrat.CoreTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.072 sec

Results :

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

[INFO] [cobertura:cobertura {execution: default-cli}]
[INFO] Not executing cobertura:report as the cobertura data file 
(/var/lib/hudson/workspace/MyProject/trunk/target/cobertura/cobertura.ser) 
could not be found
[WARN]  Cobertura report not found at 
/var/lib/hudson/workspace/MyProject/trunk/target/site/cobertura/coverage.xml

Do you have any idea of the problem? Does it come from AMP plugin, cobertura 
plugin or Maven core?

Thanks

Julien

[1] http://wiki.alfresco.com/wiki/Managing_Alfresco_Lifecyle_with_Maven
[2] 
http://maven-alfresco-archetypes.googlecode.com/svn/trunk/plugins/maven-amp-plugin/src/main/resources/META-INF/plexus/components.xml
[3] 
http://svn.codehaus.org/mojo/tags/cobertura-maven-plugin-2.3/src/main/java/org/codehaus/mojo/cobertura/CoberturaInstrumentMojo.java





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura jetty

[Douglas Ferguson]

Actually switching to emma got things working..

I just start jetty from the base class of my selenium test.
I have a static field that prevents jetty from attempting to start twice.

Seems to work great.

D/

On Mar 4, 2010, at 11:23 PM, hanasaki wrote:

 most of what I have found points to using emma to get code coverage in 
 the integration phase using the failsafe plugin and embedded Jetty.
 
  Original Message 
 Subject: cobertura  jetty
 From: Douglas Ferguson doug...@douglasferguson.us
 To: Maven Users List users@maven.apache.org
 Date: 03/04/2010 10:43 PM
 
 So I finally got jetty starting from my test case, but it doesn't
 impact the code coverage.
 
 My BasePage class is at 0% which is confusing.
 
 The server is started from the test class which would make you think
 would be using the instrumented classes and jetty would inherit the
 same classpath.
 
 What am I missing?
 
 Douglas 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
 additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura jetty

[Kalle Korhonen]

Glad to hear you got things working. Just a note on Cobertura though;
we are running our cove coverage for unit and container-based
integration tests with Cobertura so it's not the tool per se. Could
have been an issue with the version of Cobertura you were using or the
configuration but if Emma is working for you and you are happy with
it, I wouldn't switch.

Kalle


On Fri, Mar 5, 2010 at 1:05 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
 Actually switching to emma got things working..

 I just start jetty from the base class of my selenium test.
 I have a static field that prevents jetty from attempting to start twice.

 Seems to work great.

 D/

 On Mar 4, 2010, at 11:23 PM, hanasaki wrote:

 most of what I have found points to using emma to get code coverage in
 the integration phase using the failsafe plugin and embedded Jetty.

  Original Message 
 Subject: cobertura  jetty
 From: Douglas Ferguson doug...@douglasferguson.us
 To: Maven Users List users@maven.apache.org
 Date: 03/04/2010 10:43 PM

 So I finally got jetty starting from my test case, but it doesn't
 impact the code coverage.

 My BasePage class is at 0% which is confusing.

 The server is started from the test class which would make you think
 would be using the instrumented classes and jetty would inherit the
 same classpath.

 What am I missing?

 Douglas
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
 additional commands, e-mail: users-h...@maven.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura jetty

[Douglas Ferguson]

Well cobertura's graphs in hudson are far superior.

We aren't even specifying a version so we should have had the latest.

groupIdorg.codehaus.mojo/groupId
artifactIdcobertura-maven-plugin/artifactId



D/

On Mar 5, 2010, at 11:28 AM, Kalle Korhonen wrote:

 Glad to hear you got things working. Just a note on Cobertura though;
 we are running our cove coverage for unit and container-based
 integration tests with Cobertura so it's not the tool per se. Could
 have been an issue with the version of Cobertura you were using or the
 configuration but if Emma is working for you and you are happy with
 it, I wouldn't switch.
 
 Kalle
 
 
 On Fri, Mar 5, 2010 at 1:05 AM, Douglas Ferguson
 doug...@douglasferguson.us wrote:
 Actually switching to emma got things working..
 
 I just start jetty from the base class of my selenium test.
 I have a static field that prevents jetty from attempting to start twice.
 
 Seems to work great.
 
 D/
 
 On Mar 4, 2010, at 11:23 PM, hanasaki wrote:
 
 most of what I have found points to using emma to get code coverage in
 the integration phase using the failsafe plugin and embedded Jetty.
 
  Original Message 
 Subject: cobertura  jetty
 From: Douglas Ferguson doug...@douglasferguson.us
 To: Maven Users List users@maven.apache.org
 Date: 03/04/2010 10:43 PM
 
 So I finally got jetty starting from my test case, but it doesn't
 impact the code coverage.
 
 My BasePage class is at 0% which is confusing.
 
 The server is started from the test class which would make you think
 would be using the instrumented classes and jetty would inherit the
 same classpath.
 
 What am I missing?
 
 Douglas
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
 additional commands, e-mail: users-h...@maven.apache.org
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org
 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

cobertura jetty

[Douglas Ferguson]

So I finally got jetty starting from my test case, but it doesn't impact the 
code coverage.

My BasePage class is at 0% which is confusing.

The server is started from the test class which would make you think would be 
using the instrumented classes and jetty would inherit the same classpath.

What am I missing?

Douglas
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura jetty

[hanasaki]

most of what I have found points to using emma to get code coverage in 
the integration phase using the failsafe plugin and embedded Jetty.


 Original Message 
Subject: cobertura  jetty
From: Douglas Ferguson doug...@douglasferguson.us
To: Maven Users List users@maven.apache.org
Date: 03/04/2010 10:43 PM


So I finally got jetty starting from my test case, but it doesn't
impact the code coverage.

My BasePage class is at 0% which is confusing.

The server is started from the test class which would make you think
would be using the instrumented classes and jetty would inherit the
same classpath.

What am I missing?

Douglas 
-

 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [Cobertura] Multimodules : cobertura replaces artifact dependency by target/generated-classes/cobertura

[Frederic Camblor]

No idea about my issue ? :-(

On Thu, Jan 21, 2010 at 11:48 AM, Frederic Camblor fcamb...@gmail.comwrote:

 Hi all :-)

 I have a multimodule project, saying :
 - ProjectParent
 --- ProjectEAR
 --- ProjectEJB
 --- ProjectWeb (depends on ProjectEJB)

 When I launch mvn -X cobertura:cobertura
 I can see the following :
 [INFO] [compiler:compile]
 [DEBUG] Using compiler 'javac'.
 [DEBUG] Source directories:
 [D:\workspaces\Project\ProjectParent\ProjectWEB\src
  D:\workspaces\Project\ProjectParent\ProjectWEB\bouchon-src]
 [DEBUG] Classpath:
 [D:\workspaces\Project\ProjectParent\ProjectWEB\target\classes
 *
  
 D:\workspaces\Project\ProjectParent\ProjectEJB\target\generated-classes\cobertura
 *
  C:\Documents and
 Settings\fcamblor\.m2\repository\commons-beanutils\commons-beanutils\1.7.0\commons-beanutils-1.7.0.jar
  C:\Documents and
 Settings\fcamblor\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar
  C:\Documents and
 Settings\fcamblor\.m2\repository\commons-collections\commons-collections\3.2\commons-collections-3.2.jar
 [etc...]

 The red line denotes cobertura replaced my ProjectEJB jar dependency by the
 target/generated-classes/cobertura generated folder !
 Does that sound normal for you ?

 Is there a way to force cobertura to use dependency instead of adding
 source ? (it implies compilation errors in my case :-()

 Frédéric

[Cobertura] Multimodules : cobertura replaces artifact dependency by target/generated-classes/cobertura

[Frederic Camblor]

Hi all :-)

I have a multimodule project, saying :
- ProjectParent
--- ProjectEAR
--- ProjectEJB
--- ProjectWeb (depends on ProjectEJB)

When I launch mvn -X cobertura:cobertura
I can see the following :
[INFO] [compiler:compile]
[DEBUG] Using compiler 'javac'.
[DEBUG] Source directories:
[D:\workspaces\Project\ProjectParent\ProjectWEB\src
 D:\workspaces\Project\ProjectParent\ProjectWEB\bouchon-src]
[DEBUG] Classpath:
[D:\workspaces\Project\ProjectParent\ProjectWEB\target\classes
*
 
D:\workspaces\Project\ProjectParent\ProjectEJB\target\generated-classes\cobertura
*
 C:\Documents and
Settings\fcamblor\.m2\repository\commons-beanutils\commons-beanutils\1.7.0\commons-beanutils-1.7.0.jar
 C:\Documents and
Settings\fcamblor\.m2\repository\commons-logging\commons-logging\1.1.1\commons-logging-1.1.1.jar
 C:\Documents and
Settings\fcamblor\.m2\repository\commons-collections\commons-collections\3.2\commons-collections-3.2.jar
[etc...]

The red line denotes cobertura replaced my ProjectEJB jar dependency by the
target/generated-classes/cobertura generated folder !
Does that sound normal for you ?

Is there a way to force cobertura to use dependency instead of adding
source ? (it implies compilation errors in my case :-()

Frédéric

pmd, checkstyle and cobertura in multi module project

[manoj.java]

I am using pmd, checkstyle and cobertura in my project.
I have configured them all in my parent pom, which is get shared across all
my modules.

Now i want that one of the module dont use these  pmd, checkstyle and
cobertura checks.

What configuration is required to do that.

Please help me out.

Thanks in advance.
-- 
View this message in context: 
http://old.nabble.com/pmd%2C-checkstyle-and-cobertura-in-multi-module-project-tp26388033p26388033.html
Sent from the Maven - Users mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

cobertura and build-helper-maven-plugin problems

[Daniele Dellafiore]

Hi.

Take a project that has mvn test is succesfull.
Then I run mvn site, with cobertura reporting.
I have a compilation problem. In pom I configured an additional test
source folder (src/test/functional) with some dependencies (htmlunit).

plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
version1.1/version
executions
   execution
  idadd-test-source/id
  phasegenerate-test-sources/phase
  goals
 goaladd-source/goal
  /goals
  configuration
 sources
sourcesrc/test/functional/source
 /sources
  /configuration
   /execution
/executions
 /plugin

Here the log starting form the end of tests (i removed complete folder
path for privacy).
It seems that cobertura does not use dependencies with scope test
(junit, htmlunit) even if the folder is added, using
build-helper-maven-plugin, as a test source folder

=

Tests run: 64, Failures: 0, Errors: 0, Skipped: 2

Cobertura: Loaded information on 135 classes.
Cobertura: Saved information on 135 classes.
[INFO] Preparing surefire-report:report
[INFO] [resources:resources {execution: default-resources}]
[WARNING] File encoding has not been set, using platform encoding
UTF-8, i.e. build is platform dependent!
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered
resources, i.e. build is platform dependent!
[INFO] Copying 5 resources to contents
[INFO] Copying 4 resources
[INFO] Copying 40 resources
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 2 source files to
/home/ildella/projects/work/citigroup/newsautomation/target/generated-classes/cobertura
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Compilation failure

/home/ildella/.../src/test/functional/presentation/WebFunctionalTest.java:[6,36]
package com.gargoylesoftware.htmlunit does not exist

[other similar error...]

/home/ildella/../src/test/functional/presentation/WebFunctionalTest.java:[15,13]
cannot find symbol
symbol  : class HtmlPage
location: class presentation.WebFunctionalTest

[other similar error...]

/home/ildella/../src/test/functional/presentation/NewsAutomFunctionalTest.java:[6,16]
package org.junit does not exist

[other similar error...]

[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 25 seconds
[INFO] Finished at: Sat Nov 07 17:09:40 CET 2009
[INFO] Final Memory: 34M/508M
[INFO] 





-- 
Daniele Dellafiore
http://danieledellafiore.net

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: cobertura and build-helper-maven-plugin problems

[Daniele Dellafiore]

I am sorry, just change:

 goaladd-source/goal

with

 goaladd-test-source/goal

and works, btw, I already tried it but made some confusion between two pom...
Now works, but eclipse:eclipse does not generate a source folder accordingly...

On Sat, Nov 7, 2009 at 5:16 PM, Daniele Dellafiore ilde...@gmail.com wrote:
 Hi.

 Take a project that has mvn test is succesfull.
 Then I run mvn site, with cobertura reporting.
 I have a compilation problem. In pom I configured an additional test
 source folder (src/test/functional) with some dependencies (htmlunit).

 plugin
            groupIdorg.codehaus.mojo/groupId
            artifactIdbuild-helper-maven-plugin/artifactId
            version1.1/version
            executions
               execution
                  idadd-test-source/id
                  phasegenerate-test-sources/phase
                  goals
                     goaladd-source/goal
                  /goals
                  configuration
                     sources
                        sourcesrc/test/functional/source
                     /sources
                  /configuration
               /execution
            /executions
         /plugin

 Here the log starting form the end of tests (i removed complete folder
 path for privacy).
 It seems that cobertura does not use dependencies with scope test
 (junit, htmlunit) even if the folder is added, using
 build-helper-maven-plugin, as a test source folder

 =

 Tests run: 64, Failures: 0, Errors: 0, Skipped: 2

 Cobertura: Loaded information on 135 classes.
 Cobertura: Saved information on 135 classes.
 [INFO] Preparing surefire-report:report
 [INFO] [resources:resources {execution: default-resources}]
 [WARNING] File encoding has not been set, using platform encoding
 UTF-8, i.e. build is platform dependent!
 [WARNING] Using platform encoding (UTF-8 actually) to copy filtered
 resources, i.e. build is platform dependent!
 [INFO] Copying 5 resources to contents
 [INFO] Copying 4 resources
 [INFO] Copying 40 resources
 [INFO] [compiler:compile {execution: default-compile}]
 [INFO] Compiling 2 source files to
 /home/ildella/projects/work/citigroup/newsautomation/target/generated-classes/cobertura
 [INFO] 
 
 [ERROR] BUILD FAILURE
 [INFO] 
 
 [INFO] Compilation failure

 /home/ildella/.../src/test/functional/presentation/WebFunctionalTest.java:[6,36]
 package com.gargoylesoftware.htmlunit does not exist

 [other similar error...]

 /home/ildella/../src/test/functional/presentation/WebFunctionalTest.java:[15,13]
 cannot find symbol
 symbol  : class HtmlPage
 location: class presentation.WebFunctionalTest

 [other similar error...]

 /home/ildella/../src/test/functional/presentation/NewsAutomFunctionalTest.java:[6,16]
 package org.junit does not exist

 [other similar error...]

 [INFO] 
 
 [INFO] For more information, run Maven with the -e switch
 [INFO] 
 
 [INFO] Total time: 25 seconds
 [INFO] Finished at: Sat Nov 07 17:09:40 CET 2009
 [INFO] Final Memory: 34M/508M
 [INFO] 
 





 --
 Daniele Dellafiore
 http://danieledellafiore.net




-- 
Daniele Dellafiore
http://danieledellafiore.net

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

[cobertura] do not publish source code

[Daniele Dellafiore]

Hi everyone.

I want to publish code coverage for my project on a public site but
some projects are not open source. How can I avoid cobertura to
publish the source code for each class leaving all the coverage
reports?

Thanks..

-- 
Daniele Dellafiore
http://ildella.net
http://twitter.com/ildella

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

RE: [cobertura] do not publish source code

[Edelson, Justin]

Without an extensive amount of work, I suspect you could bind a custom
execution of the clean plugin in the post-site phase to remove all the
html files from target/site/cobertura EXCEPT for index.html,
frame-packages.html, frame-summary.html, frame-sourcefiles.html, and
help.html. This would lead to broken links. Not having broken links
would likely involve modifying cobertura and/or the plugin, so I'd
suggest at least trying the clean option and see how far that takes you.

Justin

-Original Message-
From: Daniele Dellafiore [mailto:ilde...@gmail.com] 
Sent: Friday, October 23, 2009 10:04 AM
To: Maven Users List
Subject: [cobertura] do not publish source code

Hi everyone.

I want to publish code coverage for my project on a public site but some
projects are not open source. How can I avoid cobertura to publish the
source code for each class leaving all the coverage reports?

Thanks..

--
Daniele Dellafiore
http://ildella.net
http://twitter.com/ildella

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [cobertura] do not publish source code

[Stephen Connolly]

or another technique would be to overwrite every html file that is in a
sub-dir with a simple html saying that the source code is confidential...
that way your links will still work ;-)

2009/10/23 Edelson, Justin justin.edel...@mtvstaff.com

 Without an extensive amount of work, I suspect you could bind a custom
 execution of the clean plugin in the post-site phase to remove all the
 html files from target/site/cobertura EXCEPT for index.html,
 frame-packages.html, frame-summary.html, frame-sourcefiles.html, and
 help.html. This would lead to broken links. Not having broken links
 would likely involve modifying cobertura and/or the plugin, so I'd
 suggest at least trying the clean option and see how far that takes you.

 Justin

 -Original Message-
 From: Daniele Dellafiore [mailto:ilde...@gmail.com]
 Sent: Friday, October 23, 2009 10:04 AM
 To: Maven Users List
 Subject: [cobertura] do not publish source code

 Hi everyone.

 I want to publish code coverage for my project on a public site but some
 projects are not open source. How can I avoid cobertura to publish the
 source code for each class leaving all the coverage reports?

 Thanks..

 --
 Daniele Dellafiore
 http://ildella.net
 http://twitter.com/ildella

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

RE: [cobertura] do not publish source code

[Edelson, Justin]

That might work. But my way was easier :)

And unless this changed recently, the cobertura report outputs the
source code files in the cobertura directory, not a subdir. I'm assuming
the OP has already shut off xref reports and other things which contain
source.

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Friday, October 23, 2009 10:26 AM
To: Maven Users List
Subject: Re: [cobertura] do not publish source code

or another technique would be to overwrite every html file that is in a
sub-dir with a simple html saying that the source code is
confidential...
that way your links will still work ;-)

2009/10/23 Edelson, Justin justin.edel...@mtvstaff.com

 Without an extensive amount of work, I suspect you could bind a custom

 execution of the clean plugin in the post-site phase to remove all the

 html files from target/site/cobertura EXCEPT for index.html, 
 frame-packages.html, frame-summary.html, frame-sourcefiles.html, and 
 help.html. This would lead to broken links. Not having broken links 
 would likely involve modifying cobertura and/or the plugin, so I'd 
 suggest at least trying the clean option and see how far that takes
you.

 Justin

 -Original Message-
 From: Daniele Dellafiore [mailto:ilde...@gmail.com]
 Sent: Friday, October 23, 2009 10:04 AM
 To: Maven Users List
 Subject: [cobertura] do not publish source code

 Hi everyone.

 I want to publish code coverage for my project on a public site but 
 some projects are not open source. How can I avoid cobertura to 
 publish the source code for each class leaving all the coverage
reports?

 Thanks..

 --
 Daniele Dellafiore
 http://ildella.net
 http://twitter.com/ildella

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [cobertura] do not publish source code

[Nick Stolwijk]

I think the changes to cobertura are not that much. And building and
deploying your own version of the cobertura-maven-plugin isn't hard either.
Take a look at cobertura's source [1], especially

generateSourceFile(SourceFileData sourceFileData)

[1]http://cobertura.svn.sourceforge.net/viewvc/cobertura/tags/v1_9_3/src/net/sourceforge/cobertura/reporting/html/HTMLReport.java?revision=687view=markup

With regards,


Nick Stolwijk
~Java Developer~

IPROFS BV.
Claus Sluterweg 125
2012 WS Haarlem
http://www.iprofs.nl


On Fri, Oct 23, 2009 at 4:29 PM, Edelson, Justin 
justin.edel...@mtvstaff.com wrote:

 That might work. But my way was easier :)

 And unless this changed recently, the cobertura report outputs the
 source code files in the cobertura directory, not a subdir. I'm assuming
 the OP has already shut off xref reports and other things which contain
 source.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Friday, October 23, 2009 10:26 AM
 To: Maven Users List
 Subject: Re: [cobertura] do not publish source code

 or another technique would be to overwrite every html file that is in a
 sub-dir with a simple html saying that the source code is
 confidential...
 that way your links will still work ;-)

 2009/10/23 Edelson, Justin justin.edel...@mtvstaff.com

  Without an extensive amount of work, I suspect you could bind a custom

  execution of the clean plugin in the post-site phase to remove all the

  html files from target/site/cobertura EXCEPT for index.html,
  frame-packages.html, frame-summary.html, frame-sourcefiles.html, and
  help.html. This would lead to broken links. Not having broken links
  would likely involve modifying cobertura and/or the plugin, so I'd
  suggest at least trying the clean option and see how far that takes
 you.
 
  Justin
 
  -Original Message-
  From: Daniele Dellafiore [mailto:ilde...@gmail.com]
  Sent: Friday, October 23, 2009 10:04 AM
  To: Maven Users List
  Subject: [cobertura] do not publish source code
 
  Hi everyone.
 
  I want to publish code coverage for my project on a public site but
  some projects are not open source. How can I avoid cobertura to
  publish the source code for each class leaving all the coverage
 reports?
 
  Thanks..
 
  --
  Daniele Dellafiore
  http://ildella.net
  http://twitter.com/ildella
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org

Re: [cobertura] do not publish source code

[Wayne Fay]

As always... if you do hack the source code, make it configurable and
donate the changes back to Cobertura so it can be considered for
inclusion in a future release. This sounds like a potentially useful
feature for a number of organizations.

Wayne

On Fri, Oct 23, 2009 at 9:41 AM, Nick Stolwijk nick.stolw...@gmail.com wrote:
 I think the changes to cobertura are not that much. And building and
 deploying your own version of the cobertura-maven-plugin isn't hard either.
 Take a look at cobertura's source [1], especially

 generateSourceFile(SourceFileData sourceFileData)

 [1]http://cobertura.svn.sourceforge.net/viewvc/cobertura/tags/v1_9_3/src/net/sourceforge/cobertura/reporting/html/HTMLReport.java?revision=687view=markup

 With regards,


 Nick Stolwijk
 ~Java Developer~

 IPROFS BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 http://www.iprofs.nl


 On Fri, Oct 23, 2009 at 4:29 PM, Edelson, Justin 
 justin.edel...@mtvstaff.com wrote:

 That might work. But my way was easier :)

 And unless this changed recently, the cobertura report outputs the
 source code files in the cobertura directory, not a subdir. I'm assuming
 the OP has already shut off xref reports and other things which contain
 source.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Friday, October 23, 2009 10:26 AM
 To: Maven Users List
 Subject: Re: [cobertura] do not publish source code

 or another technique would be to overwrite every html file that is in a
 sub-dir with a simple html saying that the source code is
 confidential...
 that way your links will still work ;-)

 2009/10/23 Edelson, Justin justin.edel...@mtvstaff.com

  Without an extensive amount of work, I suspect you could bind a custom

  execution of the clean plugin in the post-site phase to remove all the

  html files from target/site/cobertura EXCEPT for index.html,
  frame-packages.html, frame-summary.html, frame-sourcefiles.html, and
  help.html. This would lead to broken links. Not having broken links
  would likely involve modifying cobertura and/or the plugin, so I'd
  suggest at least trying the clean option and see how far that takes
 you.
 
  Justin
 
  -Original Message-
  From: Daniele Dellafiore [mailto:ilde...@gmail.com]
  Sent: Friday, October 23, 2009 10:04 AM
  To: Maven Users List
  Subject: [cobertura] do not publish source code
 
  Hi everyone.
 
  I want to publish code coverage for my project on a public site but
  some projects are not open source. How can I avoid cobertura to
  publish the source code for each class leaving all the coverage
 reports?
 
  Thanks..
 
  --
  Daniele Dellafiore
  http://ildella.net
  http://twitter.com/ildella
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: [cobertura] do not publish source code

[Paul Benedict]

Sounds like you want an exclude packages option  (or maybe granular
down to the class level) like JavaDoc.

Paul

On Fri, Oct 23, 2009 at 10:52 AM, Wayne Fay wayne...@gmail.com wrote:
 As always... if you do hack the source code, make it configurable and
 donate the changes back to Cobertura so it can be considered for
 inclusion in a future release. This sounds like a potentially useful
 feature for a number of organizations.

 Wayne

 On Fri, Oct 23, 2009 at 9:41 AM, Nick Stolwijk nick.stolw...@gmail.com 
 wrote:
 I think the changes to cobertura are not that much. And building and
 deploying your own version of the cobertura-maven-plugin isn't hard either.
 Take a look at cobertura's source [1], especially

 generateSourceFile(SourceFileData sourceFileData)

 [1]http://cobertura.svn.sourceforge.net/viewvc/cobertura/tags/v1_9_3/src/net/sourceforge/cobertura/reporting/html/HTMLReport.java?revision=687view=markup

 With regards,


 Nick Stolwijk
 ~Java Developer~

 IPROFS BV.
 Claus Sluterweg 125
 2012 WS Haarlem
 http://www.iprofs.nl


 On Fri, Oct 23, 2009 at 4:29 PM, Edelson, Justin 
 justin.edel...@mtvstaff.com wrote:

 That might work. But my way was easier :)

 And unless this changed recently, the cobertura report outputs the
 source code files in the cobertura directory, not a subdir. I'm assuming
 the OP has already shut off xref reports and other things which contain
 source.

 -Original Message-
 From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Sent: Friday, October 23, 2009 10:26 AM
 To: Maven Users List
 Subject: Re: [cobertura] do not publish source code

 or another technique would be to overwrite every html file that is in a
 sub-dir with a simple html saying that the source code is
 confidential...
 that way your links will still work ;-)

 2009/10/23 Edelson, Justin justin.edel...@mtvstaff.com

  Without an extensive amount of work, I suspect you could bind a custom

  execution of the clean plugin in the post-site phase to remove all the

  html files from target/site/cobertura EXCEPT for index.html,
  frame-packages.html, frame-summary.html, frame-sourcefiles.html, and
  help.html. This would lead to broken links. Not having broken links
  would likely involve modifying cobertura and/or the plugin, so I'd
  suggest at least trying the clean option and see how far that takes
 you.
 
  Justin
 
  -Original Message-
  From: Daniele Dellafiore [mailto:ilde...@gmail.com]
  Sent: Friday, October 23, 2009 10:04 AM
  To: Maven Users List
  Subject: [cobertura] do not publish source code
 
  Hi everyone.
 
  I want to publish code coverage for my project on a public site but
  some projects are not open source. How can I avoid cobertura to
  publish the source code for each class leaving all the coverage
 reports?
 
  Thanks..
 
  --
  Daniele Dellafiore
  http://ildella.net
  http://twitter.com/ildella
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
  For additional commands, e-mail: users-h...@maven.apache.org
 
 

 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Unit tests instrumented by cobertura are (very) slow

[Julien HENRY]

Hi,

I have a project with a few CPU intensive tests (mainly computing algorithms). 
Running mvn clean test takes about 1min30
Running mvn clean cobertura:cobertura takes about 25min!!!
Running mvn clean emma:emma takes about 2min

Does anybody know what can be the reason why JUnit tests are taking so much 
time with cobertura?

Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_15
Default locale: fr_FR, platform encoding: Cp1252
OS name: windows xp version: 5.1 arch: x86 Family: windows

cobertura plugin: 2.3
emma plugin: 1.0-alpha-2

Thanks,

Julien





-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Cobertura in EAR artefacts

[Frederic Camblor]

Hi folks !
I'm facing a problematic concerning the cobertura report.

Suppose we have an EAR Application with :
- A Business module
- A Web module

Web layer uses the Business Layer.
Unit tests are made in both Business and WEB modules.

When I run tests on WEB module, some Business classes are called during the
test process.

My problem is : I don't know how to parameterize cobertura in order to
aggregate results from Business layer during the Web Layer tests execution.

That is to say, for now on, I've only 10% of test coverage on Business layer
and 50% of test coverage on Web layer ... because they are aggregated *
independently* !
Although I'm sure I could have almost ~40% of test coverage on Business
layer with the execution of tests on Web layer :(

Someone already faced the problem ?

Thanks in advance
Frederic

Re: Cobertura in EAR artefacts

[Roland Asmann]

Ah, this unfortunately means that you *CAN'T* run the site-build as you 
normally would, since the reports are generated on a per-module basis and you 
would 'update;  your results with a later test.

So, it's best to 'manually' test your coverage or have 2 'passes' of maven's 
site-build to include the updated cobertura-results.

And maybe it needs mentioning, maybe not: stay away from the 'clean'-goal 
between these passes! :-)


On Monday 14 September 2009 18:03, Roland Asmann wrote:
 Couldn't you just package the cobertura-jars in your EAR and run
 integration-tests on them? I believe that Cobertura writes all calls to the
 respective data-files when methods are called... At least, last time I
 checked this worked for me... :-)

 To use the cobertura-jars, just add the cobertura:instrument call in the
 POM and Maven will handle the rest... Be carefull though, it's probably
 best to do this in a test-profile, since your normal artifacts will now
 have Cobertura-classes in them!

 POM-snippet:
 -- SNIPPET --
   profiles
     profile
       idtest/id
       build
         plugins
           plugin
             groupIdorg.codehaus.mojo/groupId
             artifactIdcobertura-maven-plugin/artifactId
             version2.3/version
             executions
               execution
                 idinstrument/id
                 phaseprocess-classes/phase
                 goals
                   goalinstrument/goal
                 /goals
               /execution
             /executions
           /plugin
         /plugins
       /build
       dependencies
         dependency
           groupIdnet.sourceforge.cobertura/groupId
           artifactIdcobertura/artifactId
           version1.9.2/version
         /dependency
       /dependencies
     /profile
   /profiles
 --- SNIPPET ENDS --

 On Monday 14 September 2009 17:21, Frederic Camblor wrote:
  Hi folks !
  I'm facing a problematic concerning the cobertura report.
 
  Suppose we have an EAR Application with :
  - A Business module
  - A Web module
 
  Web layer uses the Business Layer.
  Unit tests are made in both Business and WEB modules.
 
  When I run tests on WEB module, some Business classes are called during
  the test process.
 
  My problem is : I don't know how to parameterize cobertura in order to
  aggregate results from Business layer during the Web Layer tests
  execution.
 
  That is to say, for now on, I've only 10% of test coverage on Business
  layer and 50% of test coverage on Web layer ... because they are
  aggregated * independently* !
  Although I'm sure I could have almost ~40% of test coverage on Business
  layer with the execution of tests on Web layer :(
 
  Someone already faced the problem ?
 
  Thanks in advance
  Frederic

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: roland.asm...@cfc.at
Web: www.cfc.at

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Cobertura in EAR artefacts

[Roland Asmann]

Couldn't you just package the cobertura-jars in your EAR and run 
integration-tests on them? I believe that Cobertura writes all calls to the 
respective data-files when methods are called... At least, last time I 
checked this worked for me... :-)

To use the cobertura-jars, just add the cobertura:instrument call in the POM 
and Maven will handle the rest... Be carefull though, it's probably best to 
do this in a test-profile, since your normal artifacts will now have 
Cobertura-classes in them!

POM-snippet:
-- SNIPPET --
  profiles
    profile
      idtest/id
      build
        plugins
          plugin
            groupIdorg.codehaus.mojo/groupId
            artifactIdcobertura-maven-plugin/artifactId
            version2.3/version
            executions
              execution
                idinstrument/id
                phaseprocess-classes/phase
                goals
                  goalinstrument/goal
                /goals
              /execution
            /executions
          /plugin
        /plugins
      /build
      dependencies
        dependency
          groupIdnet.sourceforge.cobertura/groupId
          artifactIdcobertura/artifactId
          version1.9.2/version
        /dependency
      /dependencies
    /profile
  /profiles
--- SNIPPET ENDS --



On Monday 14 September 2009 17:21, Frederic Camblor wrote:
 Hi folks !
 I'm facing a problematic concerning the cobertura report.

 Suppose we have an EAR Application with :
 - A Business module
 - A Web module

 Web layer uses the Business Layer.
 Unit tests are made in both Business and WEB modules.

 When I run tests on WEB module, some Business classes are called during the
 test process.

 My problem is : I don't know how to parameterize cobertura in order to
 aggregate results from Business layer during the Web Layer tests execution.

 That is to say, for now on, I've only 10% of test coverage on Business
 layer and 50% of test coverage on Web layer ... because they are aggregated
 * independently* !
 Although I'm sure I could have almost ~40% of test coverage on Business
 layer with the execution of tests on Web layer :(

 Someone already faced the problem ?

 Thanks in advance
 Frederic

-- 
Roland Asmann

CFC Informationssysteme Entwicklungsgesellschaft m.b.H
Bäckerstrasse 1/2/7
A-1010 Wien
FN 266155f, Handelsgericht Wien

Tel.: +43/1/513 88 77 - 27
Fax.: +43/1/513 88 62
Email: roland.asm...@cfc.at
Web: www.cfc.at

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org