Mailing-List: contact dev-help@archiva.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@archiva.apache.org
Received-SPF: pass (athena.apache.org: domain of james.w.dumay@gmail.com
 designates 209.85.217.25 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:sender:to:subject:mime-version:content-type
         :x-google-sender-auth;
        b=Yq58kv+D9nWKW/QQ1Se3IUI6TQ6H2LcdBSFg2bsxeacdq7b3riJoUo0+HfZISJRV/I
         xy5unezosUTi9f0M3koocRFt3NJou2h8GF6sAflGCMdI6+4TvS7mvIYIzSM9oO6wFnP0
         0EJ6UTFYbkUJKvYGRvwzycYXQVy8PednqaYjU=
Message-ID: <139722840808140109q4337bdaew562972cd35e02027@mail.gmail.com>
Date: Thu, 14 Aug 2008 18:09:21 +1000
From: "James William Dumay" <james@atlassian.com>
Sender: james.w.dumay@gmail.com
To: dev@archiva.apache.org
Subject: [comments] metadata-updater consumer in 1.2
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_58842_29455697.1218701361818"

------=_Part_58842_29455697.1218701361818
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_58842_29455697.1218701361818--