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 "Resolution Process (Buckminster)"
m (Buckminster Resolution Process moved to Resolution Process (Buckminster)) |
|||
| Line 25: | Line 25: | ||
Finally, the best version and the corresponding "fixed selector" are propagated back from the version finder and the next provider in the search path is consulted (or not, if the match is perfect). | Finally, the best version and the corresponding "fixed selector" are propagated back from the version finder and the next provider in the search path is consulted (or not, if the match is perfect). | ||
| − | + | ||
| − | [[Category:Buckminster Documentation | + | [[Category:Archived Buckminster Documentation]] |
| − | + | ||
Latest revision as of 10:34, 19 July 2007
TBD TBD TBD
FROM RESOURCEMAP Update this page
Resolvment Process
The first step when resolving a query is to find the search path to use. A list of regular expressions with associated data is first consulted. The first matching regular expression is used.
Each Buckminster installation will utilize one or more resource maps (an XML document) that will map the name of a requested component to one of several search paths (see below). The resource map contains a list of pairs with a regular expression and a corresponding entry that is either the name of a search path or a pointer to another resource map. The name of the requested component is matched against the regular expressions and the first match found denotes the search path to use or a redirection to another resource map. When the latter happens, the mapping process is delegated to the other resource map.
A resource map also contains at least one site declaration.
AT SOME POINT IN THE PROCESS
Stuff
Once a provider has been instantiated, it will use its reader type to instantiate a version finder and a version query. The version query will use the version designator, the version type, and a version converter to perform it's task.
A typical scenario for the version finder would be:
- Create candidate branch selectors.
- Determine query type by asking the version query that in turn consults the version converter. If the type is:
- tags, then go find all tags on the current branch.
- branches, then go find all branches.
- change-number or timestamp, then just verify that it exists.
- For each found branch, tag, timestamp or changenumber, create a branch selector (well possibly two, see below on "fixed selector").
- Determine query type by asking the version query that in turn consults the version converter. If the type is:
- Decide on best candidate.
- Each branch selector is converted to a version (using the version converter) and the versions are compared for magnitude. The greatest version wins.
Finally, the best version and the corresponding "fixed selector" are propagated back from the version finder and the next provider in the search path is consulted (or not, if the match is perfect).