Community
Participate
Working Groups
Created attachment 194342 [details] project to import - Workspace with o.e.jdt.core and o.e.jdt.ui - Let the workspace build - Import a project - QuickAssist - which depends on the above two (I will attach the project here) - Let the new project build log0.txt contains debug info for the above - Now kill the eclipse process - Start eclipse again - A full build happens ! (see log1.txt) My question is since the build state is saved at the end of build process (as can be seen in the logs) why is it important that eclipse is closed gracefully? - Kill the eclipse process again - Start eclipse - A full build does not happen immediately this time - Close the QuickAssist project => A full build happens now! (see log2.txt) Now the question is how is closing of this project affect the other 2 projects? Neither o.e.jdt.core nor o.e.jdt.ui depend on this project.
Created attachment 194343 [details] log0.txt
Created attachment 194344 [details] log files
log1.txt ------------------------------------------------------------------------------ Fri Apr 29 15:06:46 IST 2011 - [Worker-0] Auto-Build requested, needsBuild: true state: 0 delay: 100 Fri Apr 29 15:06:47 IST 2011 - [Worker-1] Top-level build-start of: org.eclipse.jdt.core; [], org.eclipse.jdt.ui; [], QuickAssist; [], INCREMENTAL_BUILD Fri Apr 29 15:06:47 IST 2011 - [Worker-1] Invoking (FULL_BUILD) on builder: JavaBuilder(org.eclipse.jdt.core; []) Starting build of org.eclipse.jdt.core @ Fri Apr 29 15:06:47 IST 2011 Performing full build as requested by user FULL build About to compile antadapter/org/eclipse/jdt/internal/antadapter/AntAdapterMessages.java About to compile antadapter/org/eclipse/jdt/core/JDTCompilerAdapter.java ------------------------------------------------------------------------------ log2.txt ------------------------------------------------------------------------------ Fri Apr 29 15:14:20 IST 2011 - [Worker-3] Auto-Build requested, needsBuild: false state: 4 delay: 100 Fri Apr 29 15:15:07 IST 2011 - [Worker-1] Auto-Build requested, needsBuild: true state: 0 delay: 100 Fri Apr 29 15:15:08 IST 2011 - [Worker-1] Top-level build-start of: org.eclipse.jdt.core; [], org.eclipse.jdt.ui; [], INCREMENTAL_BUILD Fri Apr 29 15:15:08 IST 2011 - [Worker-1] Invoking (FULL_BUILD) on builder: JavaBuilder(org.eclipse.jdt.core; []) Starting build of org.eclipse.jdt.core @ Fri Apr 29 15:15:08 IST 2011 Performing full build as requested by user FULL build About to compile antadapter/org/eclipse/jdt/internal/antadapter/AntAdapterMessages.java About to compile antadapter/org/eclipse/jdt/core/JDTCompilerAdapter.java ------------------------------------------------------------------------------ Looks like the platform requests for a full build in both cases, hence it may be a platform bug. But before this bug can be moved to platform for comment we should know if the Java builder really cares if eclipse crashed or not?
As far as remember, if Eclipse crashes we don't trust the build states.
(In reply to comment #4) > As far as remember, if Eclipse crashes we don't trust the build states. For me, more often than not Eclipse does not crash in the middle of a build operation, hence the build state should be good. I think on restart it might be useful to prompt the user (Firefox style) 'Well this is embarrassing, Eclipse crashed. The build state may be inconsistent, do you want to rebuild the workspace?'.
(In reply to comment #5) I see your point and I agree this would sometimes be handy. I see 2 problems with showing a prompt: 1. This needs to be done at the platform level, not inside each builder (don't want stacked dialogs...). It could also be interesting to offer more options for other state to rebuild (e.g. search indexes). 2. The prompt blocks the build forever. Without the prompt, the user could at least relaunch Eclipse and then go get a coffee. With a dialog, you always have to wait until the dialog shows up.
(In reply to comment #6) > 2. The prompt blocks the build forever. Without the prompt, the user could at > least relaunch Eclipse and then go get a coffee. With a dialog, you always have > to wait until the dialog shows up. You could have a timeout of say 10-15 seconds, and if the timeout elapses just rebuild everything. 10-15 seconds will not hurt much if rebuilding the workspace takes anything more than 4-5 minutes.
-1 for a prompt. Moving to Platform to reduce full builds after a crash if one can trust the build state (e.g. no build was running and none was scheduled).
This is probably related to being unable to compute incremental build deltas after a crash. Needs some investigation to see why.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
