Brett Porter wrote:
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/
I've tried out the proxying and checked out the metadata merging stuff
today, they both worked smoothly for me :)
Great work Joakim! :-)
-Deng
