archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <>
Subject Archiva Description
Date Tue, 05 Dec 2006 23:11:30 GMT

I was trying to come up with a description of what it
would take to make a repository really trustworthy.  

As I was writing it I thought...didn't I see something
like this on the Maven site.

So here I am.

Anyways, I wrote the description in a cookbook format.

If this matches a subset of what archiva does, then we
could use the description in the archiva documents

If there are differences I would be really interested
in what they are.

I'll be glad to incorporate them into the description
and resubmit, if someone has time to review the info.

Here it is (Thanks):


     Ensuring that versioning 
     happens on maven repository artifacts,
     along with signature checking on repository
     provided dependencies.


     See discussion

     Developers need to be assured
     that the versions they have in their
     local repository are not 
     updated WITHOUT a corresponding
     version revision.
     For example suppose 
     someone wants to try out
     ApacheDS, and they also want to build
     it themselves.  Suppose that ApacheDS
     has the following dependency:
     Suppose the provider of SuperImportantArtifact
     makes a few changes and uploads the changes
     to ibiblio, however the provider forgets to 
     change the version correspondingly.
     Next someone checks out the ApacheDS build
     and builds it.
     Maven downloads the dependencies it needs
     from Ibiblio, including SuperImportantArtifact.
     However the developer is getting build errors.
     We know why in this case.
     How do we insure that this case does not happen.

 * Artifact Download Concern
     Have the repository deployer calculate a checksum
     for artifacts and write the checksum to
repository meta
     data.  When maven deploys and artifact, have it
write the 
     checksums into the pom artifact for all the
     and rewrite it's own pom with these checksums
built in.
     So now if someone checks out the build from
     the pom is checksum aware, and can validate the
     checksum using repository meta data for
dependencies that it 
 * Artifact Upload Concern    
     Create a Maven Repository Server that performs
     revision checking.  If someone tries to upload
     an artifact without changing the version
     and existing artifact), the server complains and
     the complaint back to maven.  Maven then just
     it to the console.
     This ensures that an artifact does not get 
     overwritten without changing the version.

 * Summary
     I think with the above two concerns address the
     should be fairly tight.  We have a unique
signature on 
     dependencies, so we match this up with the
signature on the
     repository before the dependency is downloaded. 
If the signatures
     don't match, we cancel the build.
     We also check the upload to make sure that
version revision happens.

Any questions? Get answers on any topic at  Try it now.

View raw message