Community
Participate
Working Groups
If a category is checked in the Install New Software dialog and the "Work With" site is changed to a different repository which also contains a category with the same name it will remain selected regardless of the categories containing different content. The most obvious example is to find two sites with an Uncategorized category: jar:http://wiki.eclipse.org/images/5/5a/Metareq.zip!/ http://www.eclipse.org/equinox/p2/testing/updateSite
marking M7 to investigate. There is an additive check state cache that is used to work around some platform UI bugs, so IU's selected in one repo could appear as selected in another repo. However I would only expect this to occur if the category IU's appeared equal, and I would have thought that the categories would have site qualified id's.
moving to RC1. I wouldn't want to put a fix in for this on the last day of M7, it's not that important. It may not be important enough for RC1, but it should be investigated.
I think we are going with Bug 261104 instead of bug 274673. From the point of view of this bug, they should accomplish the same thing. (unique version numbers vs. unique qualifiers... in the end, we're unique).
thx, Ian. Ignore my remark in bug 274673, I hadn't seen this yet.
reassigning to John for verification as he has some spare cycles... Since this should be fixed by a publisher change, you want to verify it using recently created sites.
It appears that unique category versions doesn't fix this. Also (this may be relevant). If I have two different repos (foo and bar) with a shared Category "My Category". When I select My Category in Foo, the details pane shows Foo's version of My Category. When I change to Bar, the details pane still shows Foo's version of My Category, and only when I explicitly click on My Category again, does the details pane get updated.
Reassigning to Ian. The theory is that this should work when bug 261104 is fixed. (It has been reopened).
Susan, I was looking at this, and it appears that the publisher won't fix this problem. When the input changes on the structured viewer, it attempts to preserver selection. Since the the two different CategoryElements resolve as being equals (they have the same name), JFace will think they're the same object, and preserve the selection automatically. We could add a listener and clear the selection when the input changes, or leave this as a "feature".
(In reply to comment #8) > Susan, I was looking at this, and it appears that the publisher won't fix this > problem. > > When the input changes on the structured viewer, it attempts to preserver > selection. Since the the two different CategoryElements resolve as being equals > (they have the same name), JFace will think they're the same object, and > preserve the selection automatically. > > We could add a listener and clear the selection when the input changes, or > leave this as a "feature". > thanks, Ian, I think we can leave this as is for 3.5. Removing milestone and assignee. (At least it caused us to revisit bug 261104!) I was thinking about IU equality when I blamed this bug on bug 261104, but I forgot that we have specific category element equality in place, too. A related equality issue is that if you expand an "Uncategorized" category, it will be expanded in other sites. Same issue. Looking at the code, I can't remember why we needed merge key (name-based) equality to make the expansion state work (bug 235288). It seems like IU-based equality would have worked, but I recall it wasn't enough. When revisiting this issue, need to write some comments for equals() so I'll remember this one next time.
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.
That doesn't appear to be the case when I just tested with a recent release.
