I know how to deploy *artifacts* to the repository, but usually if it's something public it will grab it from an upstream repository if it's not in ours, so I'm not sure why the plugin is different (why it isn't getting the version from somewhere upstream). So this implies that I need to download the 2.2 plugin from somewhere else (where?) and then deploy it into our local repo?
On 7/18/08 11:59 AM, "Dennis Lundberg" <[EMAIL PROTECTED]> wrote: > 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 >> >> >> > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
