Jump to: navigation, search

Difference between revisions of "Project update sites"

(Project Update Site Responsibilities -- attempting to be more specific about requirements and expectations)
 
(clarified meaning of "platform feature".)
Line 1: Line 1:
 
Its assumed everyone is familiar with update sites and the [http://wiki.eclipse.org/index.php/Callisto_Coordinated_Update_Sites#Related_Links_for_Further_Enjoyable_Reading_and_Reference 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.  
 
Its assumed everyone is familiar with update sites and the [http://wiki.eclipse.org/index.php/Callisto_Coordinated_Update_Sites#Related_Links_for_Further_Enjoyable_Reading_and_Reference 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.  
+
* 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. And, I should clarify, by "Platform Feature" here, I mean only the platform component of the Eclpse Project (not JDT and PDE).  
  
* It is suggested that all projects provide their own discovery sites.
+
* 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).  
 
** 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).  

Revision as of 01:17, 9 February 2006

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. And, I should clarify, by "Platform Feature" here, I mean only the platform component of the Eclpse Project (not JDT and PDE).
  • 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].