Bugzilla – Full Text Bug Listing
| Summary: | Launch doesn't wait for build if launching while "cleaning" before build | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darin Wright <darin.eclipse> | ||||
| Component: | Debug | Assignee: | Jared Burns <jared_burns> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cocoakevin, john.arthorne | ||||
| Version: | 3.1 | ||||||
| Target Milestone: | 3.1 M5 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Darin Wright
Can't reproduce. Can you provide detailed steps? (put in wrong bug)
* launch workbench
* switch to Java persepctive
* start a long build (clean all)
* launch last, in debug mode
* switch to debug persepctive (manually)
> nothing in debug view, but progress view shows launch is pending on build
Created attachment 17732 [details]
screen shot
see empty debug view, and progress view
I still can't reproduce. The "dummy launch" is just a launch that's added to the launch manager. If the debug view isn't showing it, it shouldn't show any other launches either. You should be able to reproduce this bug without a build going since we're just adding a launch in both cases. A regular launch appears for me. In fact, I found that starting from the debug persepctive with a empty view causes the same thing. Looking more closely, it's because the launch is in the state of building, rather than waiting for the build even thought it was launched after the build started. If the launch is performed while the "clean" before a build is occurring, the launch job is pending, but no dummy launch appears. I'm not sure how we can tell if an active job will trigger a build, and thus, when/if to insert the dummy launch in these cases. This isn't a "dummy launch" problem. It's just a launching problem. We don't wait for a build to finish if it's in the clean state. Logically, I'd expect that if I click "Clean..." then "Launch", those two things should happen serially (with the prefs set accordingly). Adding JohnA for comment. To wait for the build to finish, we're currently calling: jobManager.join(ResourcesPlugin.FAMILY_AUTO_BUILD, monitor); jobManager.join(ResourcesPlugin.FAMILY_MANUAL_BUILD, monitor); I looked at the ResourcesPlugin constants, but didn't see anything related to the "cleaning" state. Is there some way for us to wait for the entire operation (clean + build)? NOTE: the behavior I see is that the launch does wait for the clean + build, (since the launch triggers a build itself). The problem is that we cannot detect that it's going to wait for the build to finish when the "clean" is in progress and before the build starts, because there's not BUILD family jobs in the queue. "Clean" falls under FAMILY_MANUAL_BUILD. The clean action in the UI was not honouring this setting though. I have released a fix to HEAD in org.eclipse.ui.ide (about a minute ago). DW, the launch won't wait if you turn off the option to build before launching. :-) JohnA, coolies. One question, though. Will the clean + build act like one operation? The behavior we want is: 1. Start clean. 2. Join on build. 3. Finish clean. 4. Start build. 5. Join returns. Proceed with launch. If the clean and build are separate, we'd get: 1. Start clean. 2. Join on build. 3. Finish clean. 4. Join returns. Proceed with launch. 5. Start build. I just checked out the ui.ide plugin and it looks like we're getting the latter. My test case: 1. Turn off the "Build before launching" option. 2. Select "Project > Clean...". Choose to clean the entire workspace. 3. Press F11 to relaunch. 4. When the Clean finishes, the launch proceeds (while the build is getting started). Try reversing your joins. When autobuild is turned on, the autobuild starts at the end of the clean. In your code it looks like you joing autobuild first, and manual build (clean) second. Thus you're not catching the autobuild that starts after the clean finishes. I'll try that, thanks. Adding Kevin for comment because I think he was the one who wrote the current joins. Is there any reason for the current ordering? Reversing the ordering seems to fix the bug. I'll wait to hear from Kevin before releasing in case there are any side effects I haven't considered. I didn't realize the order of the joins mattered. There is no reason to the current ordering. Fixed in DebugUIPlugin. Please verify, DW. Verified. I noticed that you have this join code in two methods (DebugUIPlugin.launchInBackground and launchInForeground). I suspect you'll want to fix up the order in both? Of course. Fixed in DebugUIPlugin. Please verify, Jared. |