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 Filters"
(→Different ways to implement filters) |
|||
Line 19: | Line 19: | ||
metadata as a dependency graph, filters can be defined on edges and/or on nodes: | metadata as a dependency graph, filters can be defined on edges and/or on nodes: | ||
− | # Node filter. Filter defined directly on the IU. This satisfies use 1) above. | + | # Node filter. Filter defined directly on the IU. This satisfies use 1) above. This doesn't work for 2), because different consumers may want to apply filters different. |
− | # Edge filter. Filter defined on | + | |
+ | # Edge filter. Filter defined on a RequiredCapability. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer. | ||
[[Category:Provisioning|Filters]] | [[Category:Provisioning|Filters]] |
Revision as of 11:37, 10 July 2007
The Equinox Provisioning mechanism needs the ability to filter and select what gets installed. This page contains some rambling thoughts on filters.
Different reasons for filtering
There are various reasons why we need filtering capabilities:
- Filters based on properties of my installation environment.
- os, ws, nl, arch
- It makes sense to specify these filters directly on the affected IU Often this is an implementation detail of the producer, and is not a concern for a consumer (group). Today perhaps core.resources requires win32, and tomorrow perhaps it will not.
- Filters as a way slicing up functionality (core, UI, doc, help, etc)
- It is the producer's role to define what slices are available
- It is the consumer's role to decide what slices they want
- A consumer higher in the dependency chain may want to override a decision made lower down in the chain.
- A consumer higher in the chain may want to constrict/simply the set of choices available lower down
Different ways to implement filters
There are different ways of exposing filters in the metadata. If you think of provisioning metadata as a dependency graph, filters can be defined on edges and/or on nodes:
- Node filter. Filter defined directly on the IU. This satisfies use 1) above. This doesn't work for 2), because different consumers may want to apply filters different.
- Edge filter. Filter defined on a RequiredCapability. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer.