maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@maven.org>
Subject Re: Deploying Staged Releases
Date Sun, 01 Apr 2007 13:43:41 GMT
I will test this once more today with the Ant Tasks, then I'll write  
it up and put the plugin up for a 1.0-alpha-1. It's really a stopgap  
until we have a proper solution but will work for any of our releases  
in the meantime.

Jason.

On 1 Apr 07, at 9:21 AM 1 Apr 07, Jason van Zyl wrote:

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


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


Mime
View raw message