Project update sites

Its assumed everyone is familiar with update sites and the basics of creating them. This page is to spell out some of the details or changes from what might have been done in the past.

• One change (that's being proposed) is that only the Platform Feature will list the Callisto site as its discovery site. This is because the Platform Feature will have to be installed first, before update manager even works, and we want the provided discovery site to point to the central site discovery site. The Platform Feature will still have the Eclipse Project's update site as its update site, since that is where fixes and future maintenance releases come from.

• It is suggested that all projects provide their own discovery sites.

• • One reason for this is that once the basic, Callisto-version of the feature is installed, then the extra discovery site would be a good mechanism to provide the non-Callisto features (as one example, the Eclipse Project might want to make their releng tool or their runtime-tools available there on their "extra" discovery site).

• • Also, some users may simply want one very specific thing and they may be expert enough to know how to go exactly to that site and get the one small thing they want.

• • Another reason, and recommendation, is that closely related (or, mutually beneficial) projects list each other as additional discovery sites. This again is simply good practice. For example, there's some "WTP scenarios" that are much cooler if BIRT or TPTP is installed in addition to WTP, though they are not "required". Hence they could all list each other as discovery sites, so, if a user installs one, then that user would be more likely to "discover" this related projects.

• Another change (that's being proposed) is that all update URL's and discovery URL's be supplied in the "find the nearest mirror form". [Still need to confirm if this really applies to update and discovery sites, or if it is only recommended in site.xml files when specific files are referenced].