Community
Participate
Working Groups
in i0413 - Open target file that includes the Helios repo as a software site - disable categorization - select a number of features to add including say the Teneo EclipseLink SDK - save and set a target platform. - notice that there are some compile errors. Hmm, missed something - reopen the target editor and edit the Helios repo entry - Type teneo in the filter field - note that the Teneo EclipseLink SDK is still selected - select also the Teneo EclipseLink Runtime feature - save the changes - sigh when you then notice that ALL other features under the Helios entry in the target definition have been removed. - Edit the Helios entry again - type RCP in the filter field - Notice that that Edit Content dialog shows an error saying that At least one item must be selected. Note that this happens every time for me and it does not matter what features you use in the example. Seems like the act of typing in the filter field is clearing the checkboxes. I recall a bug like this in 3.5 as well. there was some contention as to whether it was an SWT bug or PDE or p2 problem. Please consider disabling the filter field if using it is basically guaranteed to cause data loss.
This bug isn't a problem with the editor, it is an issue when selected software/features from p2 repos. PDE reuses the available IU group from p2. Marking as a dupe of the open issue in p2. *** This bug has been marked as a duplicate of bug 235654 ***
Reopening as per discussion on bug 235654.
Marking for RC1, will look at it earlier if possible. Need to either find an alternative workflow without drastically changing the UI code :) or find a hack in the wizard. What if when editing an existing location, we looked at the features that were previously selected and only remove them if they are visible and unchecked. If the user purposely unchecked them they would be removed, but if they were filtered they would stay. If the user checked a bunch of things but then filtered to get only what they wanted we would only add the visible features. This retains some of the wizard behaviour that could be described as a 'feature'.
might work. you'd have to be careful of flows where the user has 8 things selected, filters on "foo", some stuff gets unselected for free, user does some stuff and then filters on "bar" etc. This is a pretty common workflow I think. Hmm, I want to add EMF and EclipseLink to my target. - filter on EMF, add some stuff - filger on ElcipseLink, add som stuff, - ...
Doesn't look like this is going to happen for 3.6.
Sigh. this is very painful.
for proper tracking I added the polish keyword and moved the polish list entry from P2 to PDE since this bug got bounced back from there.
Weren't there improvements in this area? I still see issues with things not being selected at all (i.e., no selections) but seem to recall some work happening in the area of somethings but not others being selected.
I spent some time today on this and there seems to be a few issues. The first issue is the other bug (bug#235654) where items that are hidden from view because of the filter are not selected. However, there also seems to be an interesting race condition here. When the view is opened two thing happen: 1. The repository is loaded 2. The set things already selected, are re-selected. However, if the repository is not cached that job takes longer. The "re-selection" simply doesn't do anything (because the tree isn't populated yet), and when the view is finally populated, nothing is checked. I have a fix for Bug#235654, but since I keep hitting this race condition while testing I don't want to release it yet. I'll keep investing this.
(In reply to comment #9) > I spent some time today on this and there seems to be a few issues. The > first issue is the other bug (bug#235654) where items that are hidden from > view because of the filter are not selected. > > However, there also seems to be an interesting race condition here. When > the view is opened two thing happen: > 1. The repository is loaded > 2. The set things already selected, are re-selected. > > However, if the repository is not cached that job takes longer. The > "re-selection" simply doesn't do anything (because the tree isn't populated > yet), and when the view is finally populated, nothing is checked. > > I have a fix for Bug#235654, but since I keep hitting this race condition > while testing I don't want to release it yet. I'll keep investing this. To fix this race condition we would need to know when the repository information has been fetched. See Bug 330715. On that bug Susan also suggests there is a 'synchronous' mode we could try.
(In reply to comment #10) > To fix this race condition we would need to know when the repository > information has been fetched. See Bug 330715. On that bug Susan also > suggests there is a 'synchronous' mode we could try. Thanks Curtis, that was exactly what I was seeing while debugging this. Turns out that while the race condition sucks, it happens while self hosting because of the way we launch our runtime workbench. We use locations like ~/somewhere/Runtime-Workbench(7), and it's the parentheses that cause problems. These 'locations' are used as filters when we get the p2 agent, and OSGi (ldap filters) don't like them. Therefore we create a new agent each time, which means we reload the repo each time, which means that this race condition surfaces. That was a long way of saying I have this bug fixed (we now add filtered content), but the race condition is still there (bug 330715). Unless there are any objections, I'll push the fix into master so we can test it.
This needs to be looked at again in Luna as Bug 235654 was fixed in Kepler.
Looks like the fix to 235654 fixes this entirely. Free bug fix!
