archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Maria Odea Ching" <>
Subject Re: [comments] metadata-updater consumer in 1.2
Date Thu, 14 Aug 2008 08:58:23 GMT
On Thu, Aug 14, 2008 at 4:09 PM, James William Dumay <>wrote:

> 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.

Hmm, what if the metadata is broken or corrupted (ex. there are versions
specified in the metadata but doesn't actually exist in the repo)? Will the
metadata be checked for that & get updated too?

> 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?

Sounds good to me :)

> Thanks,
> James


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