archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James William Dumay" <ja...@atlassian.com>
Subject [comments] metadata-updater consumer in 1.2
Date Thu, 14 Aug 2008 08:09:21 GMT
Hey guys,
I've been working on making the metadata merging in trunk a little saner by
using the RepositoryMetadataMerge/Reader/Writer instead of those in
MetadataTools.

Part of this work is to remove our use of VersionedReference,
ArtifactReference, etc as at best their logic guesses the groupId,
artifactId and version - a source of many bugs.

What I want to discuss is the possibility to change the way that the
metadata-updater creates and updates metadata.

Currently the updater works by:
1. consuming artifact events
2. converting those paths to ArtifactReference
3. ArtifactReference is passed to MetadataTools.updateMetadata()
4. updateMetadata() converts the ArtifactReference back to a path.
5. Repeats steps 2 to 4 but using a VersionedReference.

How I propose this will work:
1. consume both POM artifact and metadata events
2. create a new maven-metadata.xml if it does not exist (Only if the event
was a POM event)'
4. check if a metadata update is actually needed (ie, if the artifact is
already in the existing metadata, do nothing).
3. Merge metadata given a new POM event or metadata event.

Advantages:
* cuts out the lossy conversion from path -> Artifact/VersionedReference ->
path
* can figure out the correct location, groupId, artifactId and version of
the metadata file to be updated or created by reading POM metadata.
* You would be able to transform a local repository into a server repository
* This implementation will have unit tests.

Disadvantages:
* May not have the entire model available on disk. In this case if the
parent is needed for a new metadata file to be written then we simply do
nothing with this consumer event. Later scans will probably happen at a time
when the parent becomes available.
* Walking the POM inheritance tree may be a little slower as you will need a
read/parse for every time you want to go up one level in the tree.

Thoughts? Questions?

Thanks,
James

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message