maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Deploying Staged Releases
Date Sun, 01 Apr 2007 13:21:32 GMT
Hi,

Yesterday I whipped off a staging repository copier and it focuses on  
pulling from any source, but only deploys using scp. I did this  
because it's the only method we have for reliably getting a release  
to a server and being able to recover if something goes wrong.  
Ideally this would be done on a single machine to be the most  
reliable, and a custom protocol will most likely be needed as our  
repository structure does make it a little tricky to pull off a  
deployment in a completely atomic fashion, but this new tool comes  
pretty close. It does the following:

1) Pulls the contents of the staging repository to the local machine.

2) Looks for any metadata in the staging repository and finds any  
matches in the target repository and downloads the metadata from the  
target repository and gives it a different name.

3) The metadata from the staging repository is merged with the  
metadata from the target repository

4) All metadata and version directories are given a suffix like the  
following:

maven-artifact
|-- 2.0.6.rip
|        ... (all the artifacts/sources/javadocs)
|-- maven-metadata.xml.md5.rip
|-- maven-metadata.xml.rip
`-- maven-metadata.xml.sha1.rip

5) A shell script is generated which knows how to renamed the  
suffixed resources to something Maven can utilized

6) The deployment is zipped up along with the renaming script

7) The zip file is moved to the root the target repository

8) The zip is unpacked, overwriting anything of the same name

9) The rename script is run to make the above look normal like:

maven-artifact
|-- 2.0.6
|        ... (all the artifacts/sources/javadocs)
|-- maven-metadata.xml.md5
|-- maven-metadata.xml
`-- maven-metadata.xml.sha1

So up to 8) if anything goes wrong at worst you are left with some  
crap ".rip" directories or crap .rip metadata files. Maven doesn't  
know what these are and no user will be affected. We can write a  
shell script to clean these directories up. The rename script was the  
only thing I could come up with that was as close to atomic as we can  
get. Ideally a whole release would be contained in a single directory  
which would then make a release atomic because it's a single rename  
operation which in most OSes (I can't think of any that aren't) this  
is atomic. I tested this with Maven 2.0.6 itself and all the metadata  
is updated correctly and the content is moved over properly.

I also take into account the recalculation of the checksums after the  
merging of the metadata so those are updated as well and given the  
suffix and moved into place by the rename script. The only thing I'm  
not doing is the recalculation of the PGP signature. I ran out of  
time as I wanted to do the release. I can live with that and will try  
to incorporate some Java tool to do this.

That's the update. 2.0.6 is released, now I'll do the Ant Tasks and  
try this tool again.

Jason.




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message