This seems to make sense (though the concurrency issues are
concerning, especially considering difficulty to test)
- Brett
On 31/08/2007, at 2:56 AM, Joakim Erdfelt wrote:
In the past 2 weeks I've made tremendous progress on the Metadata
issues within Archiva.
So far in trunk, the following changes have been made.
archiva-repository-layer:
[NEW] MetadataTools component that is responsible for the merging
and updating of inplace maven-metadata.xml files.
archiva-proxy:
[Update] DefaultProxyConnector now will ...
1) download requested maven-metadata.xml from *all* remote
repositories.
NOTE: must pass the pre-download policies first.
2) Save the downloaded maven-metadata.xml next to the maven-
metadata.xml that exists in the managed repository using a filename
format of maven-metadata-${proxyId}.xml (similar to how the maven 2
local repository works now).
3) After all of the downloads from all proxied repositories
complete, a MetadataTools.updateMetadata() call is issued to
perform an update on that maven-metadata.xml file.
4) Upon a completion of the MetadataTools.updateMetadata() with
no error, the maven-metadata.xml file in the managed repository is
returned to the requesting client.
What's left.
archiva-core-consumers:
[NEW] MetadataUpdaterConsumer - which runs as part of the
repository scanning process and updates all of the in-place maven-
metadata.xml files.
Alsø Alsø Wik: I'm only mildly worried about Concurrency issues
with this solution, as most calls for the maven-metadata.xml will
be caught by the pre-download policies, and updates to those files
will occur only on occasion.
Feel free to rip my logic to shreds and tell me what an idiot I am.
(it's really the only way I'll learn) :-)
- Joakim
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
