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).
My question is whether this is expected behaviour or whether it's a bug? 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.
With kind regards,
Duncan Doyle
