Community
Participate
Working Groups
My tests auto-generate projects to facilitate debugging bad Java generation. Consequently files such as ,project and MANIFEST.MF may change without the the platform / Package Explorer noticing; fair enough. But if the auto-generated project was closed, surely opening it should refresh before opening, since surely while closed Eclipse has ignored changes? I find, for instance, that opening a previously no-nature auto-generated project does not show MANIFEST.MF in the Package Explorer if the .project file has been updated, while closed, to add plugin and java natures.
First, do you have 'Refresh using native hooks or polling" enabled? If so, I would expect that your project refreshes. We might have hole here that derived/hidden resources aren't. I saw bug 97432 but I disagree with that. I agree with you that we should refresh a project when opening it.
(In reply to Dani Megert from comment #1) > First, do you have 'Refresh using native hooks or polling" enabled? I don't know this feature. Searching the preferences shows that I do not use it. (I guess I kind of assumed that Eclipse was as smart as it could be about tracking the external filesystem. Changes seem to impact quite rapidly, but perhaps that is because an access occurs rapidly.) Open Project is clearly an Access. (In reply to Dani Megert from comment #1) > ... bug 97432 but I disagree with that. If Opening a Project can take 8 minutes, that is definitely a problem, but one solved by doing the refresh on a worker thread with a syncing decoration on the half open project in the Package Explorer. (A 37%, or whatever, complete hovertext might be nice too.)
(In reply to Ed Willink from comment #2) > (In reply to Dani Megert from comment #1) > > First, do you have 'Refresh using native hooks or polling" enabled? > > I don't know this feature. Searching the preferences shows that I do not use > it. > > (I guess I kind of assumed that Eclipse was as smart as it could be about > tracking the external filesystem. Changes seem to impact quite rapidly, but > perhaps that is because an access occurs rapidly.) It can have performance issues. You find the option on the 'Workspace' preference page. > Open Project is clearly an Access. > > (In reply to Dani Megert from comment #1) > > ... bug 97432 but I disagree with that. > > If Opening a Project can take 8 minutes, that is definitely a problem, but > one solved by doing the refresh on a worker thread with a syncing decoration > on the half open project in the Package Explorer. (A 37%, or whatever, > complete hovertext might be nice too.) Yes, I agree and I have never faced a long delay when refreshing.
(In reply to Dani Megert from comment #1) > I saw bug 97432 but I disagree with that. I agree with you that we should > refresh a project when opening it. Yes, I always have trouble with closed projects - after reopening (and git pull before) they usually tend to have compilation errors until one manually triggers refresh. So we should *try* to change that in 4.12.
Andrey, could you look at this?
(In reply to Dani Megert from comment #5) > Andrey, could you look at this? Yes, we will (me or Simeon).
Technical notes: I assume there is lot of code around that does open + refresh, because bug 97432 said we won't fix that since 3.1. I believe because of this we should not change the behavior of IProject.open() - I wonder what happens with this code (it will have 2x time refresh overhead!). There are projects around that are big and/or are located on NFS, or both. Refreshing such projects two times will make people crazy, see also bug 97432 comment 1. Instead of changing the default behavior of IProject.open() we should use IProject.open(BACKGROUND_REFRESH) in the most common places (various navigators), and also check if we need to slightly change logic inside IProject.open(int) to consider given BACKGROUND_REFRESH flag also for "usual" open case and not only for new projects.
(In reply to Andrey Loskutov from comment #7) > Refreshing such projects > two times will make people crazy, see also bug 97432 comment 1. Yes. Clearly a dilemma, but allowing a build to happen on a stale project is a dishonest waste of time. Suggest: a) a just-opened / just-checked-out project be marked as "stale" inhibiting builds / searches / indexes / .... b) the "stale" marker is removed by refresh c) about ?5 seconds after an open/check-out, a background refresh should be performed for still-"stale" projects. ?5 seconds is long enough for programmatic refreshes to have happened avoiding a double refresh. ?5 seconds is not too long to wait given the complexities of major re-builds. d) if multiple projects are being marked "stale", e.g. a GIT check-out of 100 projects, the ?5 seconds should retrigger to start after the last project, avoiding the current hazard of spurious premature incoherent builds.
(In reply to Andrey Loskutov from comment #7) > > Instead of changing the default behavior of IProject.open() we should use > IProject.open(BACKGROUND_REFRESH) in the most common places (various > navigators) The Package Explorer uses org.eclipse.jdt.ui.actions.OpenProjectAction, which delegates to org.eclipse.ui.actions.OpenResourceAction. This action then opens the project (without passing any flags). Unfortunately both are not internal and for this suggestion we would need to pass down more information (e.g. flags to pass to the resource open method). I don't think we want to change OpenResourceAction to just background refresh closed projects when opening those, this should be done only from views. Should we explore other options or do we add new methods? Essentially new public API. > also check if we need to slightly change logic inside > IProject.open(int) to consider given BACKGROUND_REFRESH flag also for > "usual" open case and not only for new projects. I've checked the code, for the above approach we'll need to adjust this, yes.
Looks like the documentation of IResource.BACKGROUND_REFRESH doesn't really match my expectations of a background refresh. From IResource.BACKGROUND_REFRESH: /** * Update flag constant (bit mask value 128) indicating that opening a * project for the first time or creating a linked folder should refresh in the * background. * * @see IProject#open(int, IProgressMonitor) * @see IFolder#createLink(URI, int, IProgressMonitor) * @since 3.1 */ int BACKGROUND_REFRESH = 0x80; From IProject.open(int, IProgressMonitor): * When a project is opened for the first time, initial information about the <---------------- describing behaviour for the first open also * project's existing resources can be obtained in the following ways: * </p> * <ul> * <li>If a {@link #loadSnapshot(int, URI, IProgressMonitor)} call ...</li> * <li>Otherwise, when the {@link IResource#BACKGROUND_REFRESH} flag is specified, * resources on disk will be added to the project in the background after * this method returns. Child resources of the project may not be available * until this background refresh completes.</li> * <li>Otherwise, resource information is obtained with a refresh operation in the * foreground, before this method returns.</li> * </ul> This describes the current implementation, and seems to have been done *specifically* for bug 74392 (background refresh on project creation, to avoid slow UI) and bug 301563 (import project from some previous state to avoid long refresh). So we'll be changing documented behaviour here and should change the documentation accordingly. Alternatively we can try to change the actions which open projects to trigger a refresh, but I don't find public API to do so (Workspace.refreshManager is not part of the IWorkspace API). The documentation of IResource.BACKGROUND_REFRESH describes quite a limited use case, so probably there won't be surprises for callers once we have the new behaviour. Though maybe we want a preference in Window -> Preferences -> General -> Workspace. Or maybe we want to background refresh only shared projects (e.g. with git), since those are bound to change without Eclipse knowing this. Otherwise, going with the IResource.BACKGROUND_REFRESH option, we'll need to touch platform resources, platfrom UI and JDT UI for the Package Explorer. For the Navigator and Project Explorer, the changes to OpenResourceAction and Project are enough. Andrey also mentioned copy-pasted versions of org.eclipse.jdt.ui.actions.OpenProjectAction in DLTK and CDT, I'll check those as well. It would be nice to know if someone has objections to the above described change of how IResource.BACKGROUND_REFRESH is handled by IProject.open(int, IProgressMonitor), so maybe we should ask on the developer mailing lists Andrey?
New Gerrit change created: https://git.eclipse.org/r/147981
New Gerrit change created: https://git.eclipse.org/r/149903
New Gerrit change created: https://git.eclipse.org/r/149906
New Gerrit change created: https://git.eclipse.org/r/149907
Gerrit change https://git.eclipse.org/r/149903 was merged to [master]. Commit: http://git.eclipse.org/c/dltk/org.eclipse.dltk.core.git/commit/?id=5abf258e2e650d292b1d2ea4c0489f9a8f3a7bf0
Gerrit change https://git.eclipse.org/r/147981 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=fb448eef05345b648ae77762266dc97cb3ee4fb8
Gerrit change https://git.eclipse.org/r/149906 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=79e9e0ad130dceaf88231f9aef06b7b8f8422fab
Gerrit change https://git.eclipse.org/r/149907 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=42063578323b4e891d7cb41ab15553390cfdc031
Looks good with I20190922-1800, but we need a test before we can close it.
New Gerrit change created: https://git.eclipse.org/r/149990
New Gerrit change created: https://git.eclipse.org/r/149995
Gerrit change https://git.eclipse.org/r/149995 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.resources.git/commit/?id=a49c1239a2a4d7dc23e45369c810ce508714a9f6
Thanks Simeon.
Verified with I20190923-1800.
