Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Equinox/p2/Repository Association"
| Line 2: | Line 2: | ||
# Association of repositories with installable units. How are the repositories initially seeded, and how does an administrator or bundle provider specify/control the repositories used to install/update a given IU? | # Association of repositories with installable units. How are the repositories initially seeded, and how does an administrator or bundle provider specify/control the repositories used to install/update a given IU? | ||
# Association of repositories with each other. How do groups of repositories interact to perform provisioning operations that span multiple repositories? | # Association of repositories with each other. How do groups of repositories interact to perform provisioning operations that span multiple repositories? | ||
| + | |||
| + | = Historical Information = | ||
| + | == Repository Association in Update Manager == | ||
| + | Prior to the introduction of p2, Update Manager (UM for short), had various mechanisms for managing repository associations: | ||
| + | # Feature update sites. Each feature specified the update site to be used for updating that feature. If a parent feature included a child feature, the parent feature's update site would override the child's update site. | ||
| + | # Feature discovery sites. Each feature could optionally specify one or more update sites containing features of interest to users of that features. These repositories would be shown to the user at the beginning of the install wizard workflow | ||
| + | # Associate sites. Each site 'S' could specify additional associate sites. Those associate sites would be used in the context of any provisioning operation against site 'S'. This is how Update Manager handled provisioning operations spanning multiple sites. | ||
Revision as of 17:28, 12 November 2008
This page is for collecting background information, requirements, and proposed solutions for the p2 Galileo plan item on improving the repository association model. Roughly, this problem area has two facets:
- Association of repositories with installable units. How are the repositories initially seeded, and how does an administrator or bundle provider specify/control the repositories used to install/update a given IU?
- Association of repositories with each other. How do groups of repositories interact to perform provisioning operations that span multiple repositories?
Historical Information
Repository Association in Update Manager
Prior to the introduction of p2, Update Manager (UM for short), had various mechanisms for managing repository associations:
- Feature update sites. Each feature specified the update site to be used for updating that feature. If a parent feature included a child feature, the parent feature's update site would override the child's update site.
- Feature discovery sites. Each feature could optionally specify one or more update sites containing features of interest to users of that features. These repositories would be shown to the user at the beginning of the install wizard workflow
- Associate sites. Each site 'S' could specify additional associate sites. Those associate sites would be used in the context of any provisioning operation against site 'S'. This is how Update Manager handled provisioning operations spanning multiple sites.