Aha, then you need to download and deploy the 2.2 version to your local
"central" repository. How you do that can be dependent on the software
that is serving as a repository. Usually you can use the Deploy Plugin [1].
[1] http://maven.apache.org/plugins/maven-deploy-plugin/usage.html
Todd Wells wrote:
Ok, I have a little more information -- I tracked down our local "central"
repository and for the org/codehaus/mojo/cobertura-maven-plugin I see a
maven-metadata.xml file with these contents:
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.0</version>
<versioning>
<latest>2.1</latest>
<release>2.1</release>
<versions>
<version>2.0</version>
<version>2.1</version>
</versions>
<lastUpdated>20061214204536</lastUpdated>
</versioning>
</metadata>
What is the proper way to update this versioning information in our
repository?
On 7/18/08 10:54 AM, "Todd Wells" <[EMAIL PROTECTED]> wrote:
The output for mvn help:effective-pom showed this and the work-around for
surefire mentioned below:
<reporting>
<outputDirectory>target/site</outputDirectory>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</reporting>
But when I run the cobertura task with a -X, I notice this in the output:
[DEBUG] Loading plugin prefixes from group: org.codehaus.mojo
[DEBUG] Skipping disabled repository thePlatform Maven Snapshot Proxy
[DEBUG] Skipping disabled repository thePlatform Maven Snapshot Proxy
[DEBUG] cobertura-maven-plugin: resolved to version 2.1 from repository
central
[DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo::12 for project:
null:cobertura-maven-plugin:maven-plugin\
:2.1 from the repository.
I also see this:
[INFO] Executed tasks
[DEBUG] org.codehaus.mojo:cobertura-maven-plugin:maven-plugin:2.1:runtime
(selected for runtime)
[DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:runtime
(selected for runtime)
[DEBUG] junit:junit:jar:3.8.1:runtime (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (selected for
runtime)
[DEBUG] classworlds:classworlds:jar:1.1-alpha-2:runtime (selected for
runtime)
[DEBUG] cobertura:cobertura-runtime:pom:1.8:runtime (selected for runtime)
[DEBUG] cobertura:cobertura:jar:1.8:runtime (selected for runtime)
[DEBUG] urbanophile:java-getopt:jar:1.0.9:runtime (selected for runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed -
nearer found: 1.1)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.1:runtime (selected for
runtime)
[DEBUG] org.apache.maven:maven-project:jar:2.0:runtime (selected for
runtime)
[DEBUG] org.apache.maven:maven-profile:jar:2.0:runtime (selected for
runtime)
[DEBUG] org.apache.maven:maven-model:jar:2.0:runtime (selected for
runtime)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed
- nearer found: 1.1)
[DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4:runtime (removed -
nearer found: 1.1)
[DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:runtime
(removed - nearer found: 1.0\
-alpha-9)
So it appears that I'm getting version 2.1 even though I've specified
version 2.2? Why might that be?
On 7/18/08 10:37 AM, "Dennis Lundberg" <[EMAIL PROTECTED]> wrote:
Here's the relevant issue in JIRA, which mentions the workaround you're
using:
http://jira.codehaus.org/browse/MCOBERTURA-61
But if you are really using version 2.2 you shouldn't have to use the
workaround.
Can you run 'mvn help:effective-pom' on you project and search the
output for any "cobertura" references. Just to see what you really have
configured.
Make sure that
Todd Wells wrote:
That was one of the things I tried before I emailed this list (and I just
tried it again after your email), but I still see the same symptoms in the
report -- it indicates coverage is 100%. So far the only work-around I've
found is adding this to the pom along with the plugin info:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemProperties>
<property>
<name>net.sourceforge.cobertura.datafile</name>
<value>target/cobertura/cobertura.ser</value>
</property>
</systemProperties>
</configuration>
</plugin>
On 7/18/08 9:57 AM, "Dennis Lundberg" <[EMAIL PROTECTED]> wrote:
You need to specify the version for the Cobertura Plugin, if you haven't
done so already, like this
<project>
...
<reporting>
<plugins>
...
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.2</version>
</plugin>
</plugins>
</reporting>
...
</project>
Todd Wells wrote:
Hi Dennis, I'm not sure what I'm using exactly -- how do I specify it? I
tried just specifying a dependency for version 2.2 but I got the same
behavior, so I'm not sure if that's the right way or not.
On 7/18/08 8:30 AM, "Dennis Lundberg" <[EMAIL PROTECTED]> wrote:
Hi Todd
What version of the Cobertura plugin are you using?
I believe issues like the ones you describe, were fixed in version 2.2.
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11226&styleNam>>>>>>
e
=H
tm
l&version=13090
Todd Wells wrote:
The cobertura:cobertura doesn¹t look for cobertura.ser in the place that
it
puts it!
cobertura.ser is put in target/cobertura/cobertura.ser, but the
reporting
phase of the mojo doesn¹t look there, so the report indicates 100%
coverage.
I can prove this by specifying the location manually like this:
mvn clean cobertura:cobertura
-Dnet.sourceforge.cobertura.datafile=target/cobertura/cobertura.ser
When I specify it that way, the report is correct (not 100%).
However, we don¹t want to have to remember that long environment
variable
every time. So how can I configure the pom so that it looks in the
right
place? It seems silly that the mojo doesn¹t look for this in the right
place automatically.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
