Equinox p2 Filters
Revision as of 17:42, 26 June 2007 by John arthorne.ca.ibm.com (Talk | contribs)
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. For 2), we need to be able to define the available properties on the node level.
- Edge filter. Filter defined on an IDependency. This doesn't make sense for reason 1) because it exposes producer implementation details on the consumer.