archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ole Ersoy <ole_er...@yahoo.com>
Subject One more try...
Date Wed, 06 Dec 2006 03:44:48 GMT
The first one did'nt go through I don't think...so
I'll give it another shot...

Hi,

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

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):

Challenge

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

Solution

     See discussion
     
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:
     
     
     	SuperImportantArtifact
     	SuperImportantArtifact
     	compile
               
     
     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.
     
Proposal

 * 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
dependencies,
     and rewrite it's own pom with these checksums
built in.
     
     So now if someone checks out the build from
subversion..say..
     the pom is checksum aware, and can validate the
corresponding
     checksum using repository meta data for
dependencies that it 
     downloads. 
          
 * Artifact Upload Concern    
     
     Create a Maven Repository Server that performs
     revision checking.  If someone tries to upload
     an artifact without changing the version
(overwriting
     and existing artifact), the server complains and
sends
     the complaint back to maven.  Maven then just
logs
     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
process
     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.


 
____________________________________________________________________________________
Yahoo! Music Unlimited
Access over 1 million songs.
http://music.yahoo.com/unlimited

Mime
View raw message