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 is that the Platform Feature will list the Callisto site as one of its discovery site. This is because the Platform Feature will have to be installed first, before update manager even works, and we want one of the provided discovery sites 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. And, I should clarify, by "Platform Feature" here, I mean only the platform component of the Eclipse Project (not JDT and PDE).

• It is suggested that all projects provide their own discovery sites (in addition to their update sites, although many use the same site).

• • 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 must 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 required in site.xml files when specific files are referenced].

• Another change (that's being proposed) is that all Callisto projects must use archive tags in their site.xml files which make use of the "find the nearest mirror form" of URL's, which will automatically re-direct the request to the nearest mirror.

• • This is important to transparently take advantage of the Eclipse mirroring system for distributed bandwidth.

• • This is also important, because if each project does this, then it makes it a trivial matter for others (either other Callisto features, or even third-party adopter's) to make use of those same archive tags in their own update site.xml files to transparently "get" required features.

• Callisto project's must not use the mirrorsURL of the <site> element tag, as this would be another, unnecessary choice in front of the end user.