Community
Participate
Working Groups
In bug 312169, I copied the "matchesRequirementsExpression" from QueryUtil so that I can find category members of multiple/merged category IU's. The UI gathers up same-named categories and takes the union of all of their requirements in order to present the members. We could use a method QueryUtil.createCategoryMemberQuery(IRequirement [] requirements) (or collection) Not sure if we would want to deprecate QueryUtil.createIUCategoryMemberQuery(IInstallableUnit iu) The latter may still have meaning in core, although I don't know that anyone else would use it. At a minimum we may want to change the javadoc to mention the new method. When we created the non-p2 ql equivalent (CategoryMemberQuery), it was seductive to pass in only one IU, and in fact I forgot about the merging problem until bug 312169 came up.
I think it is important that we unify the p2 category behavior. At present this is implemented in the user interface code for the install wizard. Here's a suggestion that would help that: A category is identified by its label right? So we could have: QueryUtil.createCategoryMemberQuery(String categoryLabel); The expression that selects all requirements for the merged category IU's looks like this: select(x | $0 == x.translations[$1]).requirements.flatten().unique() it uses the categoryLabel and the constant IInstallableUnit.PROP_NAME as parameters. The full query (using a curry expression since we don't want to repeat the requirements gathering: select( _, select(x | $0 == x.translations[$1]).requirements.flatten().unique(), { ui, rqs | rqs.exists(r | ui ~= r) }) This query would be useful in many other places as well where categories are represented (the b3.aggregator is one such place). It also ensures that the grouping is based on translations fetched from the target IQueryable. Another option would be to change the current method so that it extracts the label from the iu parameter. The first query could then be rewritten as: select(x | $0.translations[$1] == x.translations[$1]).requirements.flatten().unique() which means "merge the requirements for all IU's with the same translated label". The advantage of that approach would be that the API doesn't need to change at all and the old method becomes very useful.
(In reply to comment #1) > I think it is important that we unify the p2 category behavior. At present this > is implemented in the user interface code for the install wizard. Here's a > suggestion that would help that: That makes a lot of sense. > > A category is identified by its label right? So we could have: > > QueryUtil.createCategoryMemberQuery(String categoryLabel); > > The expression that selects all requirements for the merged category IU's looks > like this: > > select(x | $0 == x.translations[$1]).requirements.flatten().unique() > > it uses the categoryLabel and the constant IInstallableUnit.PROP_NAME as > parameters. The full query (using a curry expression since we don't want to > repeat the requirements gathering: > > select( > _, select(x | $0 == x.translations[$1]).requirements.flatten().unique(), > { ui, rqs | rqs.exists(r | ui ~= r) }) > > This query would be useful in many other places as well where categories are > represented (the b3.aggregator is one such place). It also ensures that the > grouping is based on translations fetched from the target IQueryable. > > Another option would be to change the current method so that it extracts the > label from the iu parameter. The first query could then be rewritten as: > > select(x | $0.translations[$1] == > x.translations[$1]).requirements.flatten().unique() > > which means "merge the requirements for all IU's with the same translated > label". The advantage of that approach would be that the API doesn't need to > change at all and the old method becomes very useful. I could argue for either of these approaches. The first is nice because it would allow later evolution of the way categories are represented (so if they were tags or some other non-IU representation the query would still make sense). We might have to say something specific about whether this name is translated for the current locale or not. The second is nice because the API doesn't change, and also, we can decide internally whether we are using the translated or non-translated string inside the method. It feels a little bit weird that the IU passed in is only used to get a name, but then, that's because the implementation of merging is weird. At this moment in time, I think I favor the second since we've already defined that API. But ask me again when it's time to implement ;-) If there's any movement toward broadening the way categories are represented the first one might make more sense.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
