Community
Participate
Working Groups
Created attachment 276149 [details] Screen recording showing file bad Project Explorer behavior Project Explorer exhibits bad behavior with my multi-module maven projects. Periodically, when I save a file, all of the expanded folders of one or more of the module projects collapse and the module projects move to different positions within the parent. See the animated gif that I attached. I made a trivial change, saved (ctrl-s), then you'll see that the open tree items in 'api-common-test' all collapse and 'api-common-test' moves above 'api-common-shared'. I am constantly having to re-open tree elements. It's killing my productivity. I only see this behavior for multi-module maven projects and only the individual module projects are effected. The other projects in the workspace are not effected.
I see similar behavior, and it is not only triggered by saving files. It is basically triggered anytime a file changes. Especially during code generation, project keep jumping around. What seems to happen is that project that are marked changed by GIT are sorted to be in top. However, sometimes it seems to switches back to alphabetic shorting. This could be while the GIT markers are being refreshed on the tree. This jumping around of projects is really annoying.
Having a closer look at what happens, its seems that the '>' decoration is sorted before 'a-z'. As such, the project moves to the top as soon as a change is detected by GIT. Most likely not a JDT bug, but eGIT or Platform.
This must be a bug in Common Navigator code. Packages Explorer doesn't show such behavior. Most likely common sorter uses *decorated* element names to sort. Rolf, is this a recent regression? In which release do you observe it?
I see the behavior on 2018-09 on Windows, it did not exist on Oxygen releases, not tested on Photon. It seems that the decoration is not taken in account all the time, refreshing (F5) on the root of the nested project makes them jumping around.
(In reply to Rolf Theunissen from comment #4) > I see the behavior on 2018-09 on Windows, it did not exist on Oxygen > releases, not tested on Photon. > > It seems that the decoration is not taken in account all the time, > refreshing (F5) on the root of the nested project makes them jumping around. This rings the bell. Is this happening for nested projects only? @Mickael - something related to your changes?
(In reply to Andrey Loskutov from comment #5) > @Mickael - something related to your changes? Could very well be.
I can confirm that it only happens only for nested projects. When 'flat' representation for projects is selected they all stay in place.
(In reply to Rolf Theunissen from comment #7) > I can confirm that it only happens only for nested projects. When 'flat' > representation for projects is selected they all stay in place. Ok. This kind of thing of
Bug 541232 is dedicated to the sorting issue and a patch should be provided very soon. Maybe it will be enough to fix this bug, we'll see. But because they're incepted from different case (this one is first about collapse and the other one about sorting), I'll keep them separated at the moment.
Can someone please give a try to https://git.eclipse.org/r/#/c/132578/ and report whether this helps or not?
I tried the patch, by applying it to my current 2018-09 install. It does not seem to have any difference. I did notice something else, in the Project Explorer: - If the sort order is correct and when I press 'F5' once, then nothing happens and the sort order remains the same. - If the sort order is incorrect (e.g. '>' on top) and when I press 'F5' once, then the projects move around and collapse, and the sort order is correct again. - When I press 'F5' twice quickly, i.e. trigger the second refresh before the first finished, then the projects move around and collapse, and the sort order becomes incorrect. The same behavior can be triggered by saving a file twice quickly, in that case, the folder/file with the current selection is not collapsed.
I think that bug 541300 could be another symptom of the same issue.
This still occurs in v4.10 (2018-12). Any update?
It could be a symptom of bug 541232 that was fixed recently. Can someone who face this issue deterministically download a recent integration build from https://download.eclipse.org/eclipse/downloads/index.html , install EGit in it and check whether the issue still happens?
I've not seen this issue happening recently (I'm using I-Builds). Assuming it's fixed then.
