Once a release have been build for Ivy or IvyDE, they should be pushed to the Eclipse updatesite so that Eclipse users will be able to update automatically their installed version of Ivy or IvyDE.

This doc is in two parts, the <a href="#setup">setup</a> of the updatesite which will be the candidate for the vote of the Ivy or IvyDE release, and the <a href="#deployment">final deployment</a> once the release is accepted.

<u>Important note:</u> in this doc, the released version is denoted as $VERSION (and have to be replaced accordingly in every commands), but this is the OSGi one, not the usually shown one, in particular for release candidate versions. For instance an Ivy version can be <tt>2.0.0-RC1</tt> but the OSGi one, and the one to use here is <tt>2.0.0.cr1</tt>.

<h1><a name="setup"></a>Build the updatesite</h1>

<h2>Push the new version</h2>

The update site svn location is there: https://svn.apache.org/repos/asf/ant/ivy/updatesite/trunk . You will update it so it will contain the new artifacts.

<ul><li>For an <u>Ivy</u> release:
The new ivy bundle have to be placed in the plugins directory of the updatesite. So you should do something like:
<code>cp ..../ivy.jar dist/plugins/org.apache.ivy_$VERSION.jar</code>

Then Eclipse needs a feature, which will be generated at the right place with an ant target:
<pre>
ant generate-ivy-feature -Divy.version=$VERSION</pre>
</li><li>
For an <u>IvyDE</u> release:
The zip distribution needs to be unpacked into the updatesite directory:
<pre>
cd dist
unzip ..../org.apache.ivyde.feature-$VERSION.zip
</pre>
</li>
</ul>

Then the deprecated versions of the plugins and the features should be removed.

<h2>Update the site.xml</h2>

The <tt>site.xml</tt> file in the <tt>dist</tt> directory should be edited so it will reference the new artifacts. You should just change the version number accordingly to the release.

<h2>Prepare the update site</h2>

The update site is optimized: the metadata of the features are aggregated into the digest.zip, and the jar of the plugins are compressed with a better algorithm.

To accomplish this task, just run at the root of your working copy of the updatesite:
<ul>
<li>For an <u>Ivy</u> release:
<pre>
ant optimize-ivy
</pre></li>
<li>
For an <u>IvyDE</u> release:
<pre>
ant optimize-ivyde
</pre></li>
</ul>

The binary files then need to be signed and their checksum computed. For the checksums, run:
<pre>ant checksum</pre>
And sign the binaries:

<ul>
<li>For an <u>Ivy</u> release:
<pre>./signIvyArtifacts.sh</pre>
</li>
<li>
For an <u>IvyDE</u> release:
<pre>./signIvyDEArtifacts.sh</pre>
</li>
</ul>

<b>Note:</b> these previous targets may optimize, checksum and sign already released artifacts. Just so a <tt>svn status</tt> to check the modified artifacts; the only modified files should be the digest.zip (with its signature and checksum) and the site.xml; then there should be the added files of the release. Then do some <tt>svn revert <i>file</i></tt> to revert the unexpected changes.

And finally commit your changes.

<h2>Test the updatesite</h2>

The updatesite is ready to be tested. You can deploy it where ever you want with the command:
<pre>svn export https://svn.apache.org/repos/asf/ant/ivy/updatesite/trunk/dist updatesite
</pre>

For both local and remote testing, as the new jars are not yet deployed on Apache mirrors, the updatesite mirroring have to be disable.
Basically it is just about modifying the site.xml and remove the reference to the eclipse-update--xml files: remove the attribute <tt>mirrorsURL</tt>.

To let the developper community test the updatesite, you can setup a staging updatesite in your public_html directory on people.apache.org. So if you deploy it on people.apache.org, in the directory ~/public_html/staging, then the developpers should setup the updatesite with the URL http://people.apache.org/~LOGIN/staging/updatesite .

<h1><a name="deployment"></a>Deployment of a release</h1>

The release is accepted, so we can tag the updatesite:
<pre>
svn cp https://svn.apache.org/repos/asf/ant/ivy/updatesite/trunk https://svn.apache.org/repos/asf/ant/ivy/updatesite/tags/$TAGNAME
</pre>
with <tt>$TAGNAME</tt> the name of the release, so it would be either <tt>ivy-$VERSION</tt> or <tt>ivyde-$VERSION</tt>.

Then backup and deploy. On people.apache.org:
<pre>
cd /www/www.apache.org/dist/ant/ivyde/
mv updatesite ~/updatesite.backup
svn export https://svn.apache.org/repos/asf/ant/ivy/updatesite/tags/$TAGNAME/dist updatesite
</pre>

<h2>Deprecated updatesite</h2>

The updatesite needs to be also deployed in its deprecated location, in the IvyDE website.

In your local svn working copy do:
<pre>
cp updatesite/trunk/dist/digest.zip* site/ivyde/updatesite
cp updatesite/trunk/dist/site.xml site/ivyde/updatesite
</pre>
And commit the changes of the website.
Next is the usual IvyDE website deployment:
<pre>
ant generate-site-ivyde
svn ci target/ivyde/updatesite
</pre>
And on people.apache.org:
<pre>
svn up /www/ant.apache.org/ivy/ivyde/updatesite
</pre>