Community
Participate
Working Groups
Build ID: I20090313-0100 Steps To Reproduce: 1. Open the "Install New Software" dialog 2. Choose "All Available Sites" 3. Enter "JDT" The feature "Eclipse Java Development Tools" commonly known as JDT would be expected to show up. However, only some additional integration features are listed. Possible solutions: 1.) Require all projects to include both the full and short name in the names of their features. 2.) Require all projects to include both the full and short name in their feature details. Include the feature details in the filter results. 3.) Enable and require all projects to include both the full and short name as some kind of keywords. Include these keywords in the filter results. Solution 3 would be the best and most flexible solution. However solution 1 or 2 should be easier and faster to implement. Pick one. I consider this a usability bug, therefore filing it as "Bug". However if you disagree on this, feel free to demote it to "Enhancements".
My vote is on solution #3 if we combine that with implementing a generic tagging mechanism in P2. This is just one of many situations where it would be very useful. Another is the current way of managing update site categories. I think that there's a danger in always choosing the solution that is "easiest to implement" since it puts more and more strain on the publisher. Require the projects to do this and require projects to do that is not an approach that can be used long term.
another possible solution is to apply the filter to the id, also. This won't always work, but in the case of jdt it would. Often the abbreviation is used in the bundle name/id. This is about all we could do for 3.5, marking for investigation.
I investigated the hack in comment #2. It was a one-liner and very tempting to do, but I decided against it for several reasons: - since this was bug was opened, the feature names have changed and in fact JDT now has JDT in its name - I found quite a few cases where "random" looking features appeared in the filter because their name was very different than id. It's disconcerting. Any solution where we filter on something that is not in the list items (id, or solution 2 or 3 as originally proposed) will only be useful if we can somehow show the user why the match occurred - we might instead consider pattern matching/camel case so that abbreviations could be found in the ways they are found in other places (open type, etc.) These are longer-term solutions so I'm removing the 3.5 milestone.
bulk update: UI bugs not yet assigned a milestone are returned to the inbox.
Closing as wontfix, given Susan's comment #3
