Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
1.0-beta-2
-
None
-
Debian GNU/Linux, Apache Tomcat 6.0.14, Archiva 1.0-beta-2, SUN JVM 1.5.0_12
Description
Hello,
I've setup an Archiva server (1.0-beta-2) on a Debian Linux machine (Tomcat 6.0.14, Sun JVM 1.5.0_12). I have a managed local repository ("internal-central") which is connected via a proxy connector to the central repository. I have another managed local repository ("release") for my own development and deployment. I've created a Maven2 plugin (to deal with our CA Harvest SCM system) which I deploy to the "release" repository. The generated maven-metadata.xml file looks as follows:
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>org.test.maven.plugins</groupId>
<artifactId>maven-harvest-plugin</artifactId>
<version>1.0</version>
<versioning>
<latest>1.0</latest>
<release>1.0</release>
<versions>
<version>1.0</version>
</versions>
<lastUpdated>20071009112946</lastUpdated>
</versioning>
</metadata>
When I then use a client to retrieve the pluging (by calling the 'mvn harvest:update' mojo), I get the following error:
"The plugin 'org.test.maven.plugins:maven-harvest-plugin' does not exist or no valid version could be found"
When I look at the 'maven-metadata.xml' file in the repository it contains this:
<?xml version="1.0" encoding="UTF-8"?>
<metadata>
<groupId>org.test.maven.plugins</groupId>
<artifactId>maven-harvest-plugin</artifactId>
<versioning>
<versions>
<version>1.0</version>
</versions>
</versioning>
</metadata>
For some reason, Archiva has regenerated the 'maven-metadata.xml ' file, removing the 'latest','release' and 'lastUpdated' version information. This, as far as I know, results in the 'no valid version could be found' error.
I've seen this behaviour also on the proxied repository ("internal-central"). For example when proxying spring jars, I notice that the 'latest' and 'release' version information, which is present in the metadata files at ' repo1.maven.org', are not present in the local central repository.
The regeneration seems to happen even when the 'metadata-updater' consumer is switched off (it doesn't update the metadata when scanning the repository when it is switched off, but the metadata is regenerated when a client tries to download the plugin).
The workaround for my problem is to specify the exact version of the plugin to be used in my pom.xml, which is something I don't want because the plugin is under heavy development. I also don't seem to understand why Archiva should even regenerate the 'maven-metadata.xml' files.