Bug 570794 - File changes done in an external editor not triggering rebuild (Refresh using native hooks or polling is enabled )
Summary: File changes done in an external editor not triggering rebuild (Refresh using...
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 4.18   Edit
Hardware: PC Mac OS X
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-31 14:35 EST by Christoph Rueger CLA
Modified: 2021-12-15 17:48 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Rueger CLA 2021-01-31 14:35:01 EST
We have a bundle / project containing some javascript files.
.js files are opened and edited in an external editor (e.g. vscode, atom etc.). 

Unfortunatelly Eclipse does not seem to recognize the external change and rebuild the bundle when saving in the external editor. In our case we need a real build, as the .js file gets build into a jar.

Only when pressing F5 / Refresh on the bundle in Eclipse it rebuilds. When editing the .js file in eclipse the bundle is rebuild instantly on save too.

Settings:

- MacOS 10.15.7
- Build automatically is enabled
- using also Bndtools
- Eclipse Settings / General / Workspace / Refresh using native hooks or polling is enabled
- Refresh on access enabled too
- Especially given the polling feature I would expect that the external file change gets picked up and the bundle is rebuild. I had the impression that it worked once after enabling the feature but not again since.
Comment 1 Christoph Rueger CLA 2021-02-22 14:37:17 EST
Just investigated a bit more: 

I found this plugin https://github.com/psxpaul/EclipseJava7Refresher which still works on Eclipse 2020-12 on MacOS 11.2.1 (Big Sur) and does exactly what I would expect. 
A change in an external editor takes roughly 4s until Eclipse recognizes the file change too and starts refreshing / rebuilding. The "Refresh using native hooks or polling" takes much longer... not sure exactly but > 30 seconds. I read 90s somewhere.

Could "Refresh using native hooks or polling" on MacOS be changed to behave like the plugin?

Also found this potentially related issue: https://bugs.eclipse.org/bugs/show_bug.cgi?id=237344
Comment 2 Christoph Rueger CLA 2021-02-22 14:41:06 EST
More related bugs: I think this one is pretty close to a solution:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=108697 and https://git.eclipse.org/r/c/platform/eclipse.platform.resources/+/74291/
Comment 3 Mickael Istria CLA 2021-02-22 16:19:37 EST
@Alex: any clue here?
Comment 4 nimo mayr CLA 2021-12-15 09:55:19 EST
Related: https://bugs.eclipse.org/bugs/show_bug.cgi?id=571064

One one the main things an IDE should do, is: to start incremental builds when user clicks the SAVE button. It is tedious to wait until the Eclipse IDE finally starts a rebuild at some point..clicking SAVE should result in an incremental build without much latency..any latency longer than 10 seconds disturbs..
Comment 5 Mickael Istria CLA 2021-12-15 14:39:13 EST
@Christoph: so the actual issue is not that build is not triggered, but that the change is not detected quickly enough?
Comment 6 nimo mayr CLA 2021-12-15 16:19:24 EST
@Mickael I don't think so, because I can see when the build starts - it will be shown in the eclipse status bar (bottom right). 

I discovered when the build is started and finished: the (changed) files are immediately detected after a build was triggered. However, the latency is, that the build is not triggered immediately after I save a (java) file. The build is triggered after an undetermined duration (e.g. 10-100 seconds after saving a (java) file). A user expects that the (incremental) build is triggered immediately when its dedicated file is saved (e.g. java file) without waiting too long.
Comment 7 Christoph Rueger CLA 2021-12-15 17:48:46 EST
(In reply to Mickael Istria from comment #5)
> @Christoph: so the actual issue is not that build is not triggered, but that
> the change is not detected quickly enough?

Correct.