If you are building and maintaining an update site, you undoubtedly will want a build process (e.g. build.xml file) that assembles the pieces. Ruthlessly automate. Here's the build.xml file that we use to build the QualityEclipse Tools Update Site.
Here are several tips derived from Glozic, Dejan and Dorian Birsan, “How to Keep Up To Date,” August 27, 2003 (http://www.eclipse.org/articles/Article-Update/keeping-up-to-date.html) which is referenced at the end of Chapter 18 of our book:
check the HTTP access to the update site
check file permissions to certify that anyone can read them
yet in the Eclipse workbench, it doesn't work at all
The problem is: you must put a trailing slash ("/") in the update site URL defined in "feature.xml" XML file. Why? Because Eclipse's Update Manager appends plug-in distribution file name to the URL you've set up there, without pre-pending with "/" ... so, instead of getting something like
"http://your.site/update/plugin_1.0.0.jar"
it gets
"http://your.site/updateplugin_1.0.0.jar"
which explains why, after all, Eclipse doesn't find your code... It's looking for an inexistent URL!
Eclipse's Update Manager will look for such disclaimers and doesn't allow you to install features that don't provide such notices. You must enter some text in the copyright and license fields defined in "feature.xml" XML file, such as:
If you've customized the build.xml file, then BE CAREFUL. Before using the various wizards to create and build your update site project, create a backup of your build.xml file. The update-site project build option will erase every build.xml it finds in the features and plugins required by the site -- which leads to lost work. To avoid this problem, create another ant build-file to hold your customization and use it instead of default the "build.xml". Or, as we have done, place the build.xml file in the update site project.