After playing with queries for awhile, we came up with the following that works for us but I'm not sure if it should:
We currently test against the following:
RCPApp F1 F2 F3
Each Feature has exactly one Bundle.
RCPApp just contains the Workbench and nothing else.
F1 contains the default Perspective and a View
F2 and F3 contain a dummy utility class with a method you can call and return a dummy int. The View has two buttons that call these two dummy methods and display dialogs with the resulting values. This is just so we have UI we can use to prove that all the bundles
F2 "includes" F3. F1 and F2 are the root bundles. We wanted to prove that updating F1 and F2 would correctly install F3 and its associated bundle.
Somewhat surprisingly (based on what's on the P2 query web site), the following query worked for us:
where $0 is a collection of IVersionedId referencing just F1 and F2.
The log shows that this query selected only F1 and F2.
You'll notice the conspicuous absence of a "traverse" function. Yet, our tests show that this works--the updated Product contains F1, F2, and F3 and the UI lets us call both the F2 and F3 utility methods..
If this is not just incidental behavior, we're happy with this. But are you?
On Mon, Dec 13, 2010 at 5:32 PM, Thomas Hallgren <thomas@xxxxxxx> wrote:
Just to clarify, the code you use for creating the newIU below, do
you use that for creating the IU's that you pass as roots to the
traverse query? If that's the case, then I understand why you have a
problem. The IU doesn't have any requirements so naturally, the
query won't find any matches.
You need to query for the root iu's first, using a standard IU query
(with id and version) and then use the result from that query as
root IU's into the traverse query. This can be done using two
queries but you can also do it one single query also, like so: