Re: [platform-debug-dev] Launching with background build

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

There is an additional complexity when lanuching...

The debugger has a preference that controls whether to build the workspace before launching (Preferences -> Run/Debug -> Build (if required) before launching). The launch support triggers an incremental build if the workspace is NOT in autobuild mode. The assumption is, if the user is not in autobuild mode, the workspace may need building, and if they are in autobuild mode, the workspace will already be built. This assumption is now invalid with the introduction of background builds. This is also coupled with a preference to save all dirty editors before launching.

So, I suggest we do this:

* Save dirty editors (if needed and preference is on)
* If the "build" preference is on, check for an existing build job.
        * If there is an existing build, and the job is running - join on it. If the job is waiting, prompt the user to see if they want to wait for the build before launching.
        * If there is no job, schedule one
* Launch if the user does not want to wait, or once the build job is done.

What is the proper way to schedule a build now? (John).

Darin

John Arthorne/Ottawa/IBM@IBMCA Sent by: platform-debug-dev-admin@xxxxxxxxxxx 09/16/2003 02:49 PM Please respond to platform-debug-dev

To:        platform-debug-dev@xxxxxxxxxxx         cc:                 Subject:        [platform-debug-dev] Launching with background build

Hello, 

I am planning on soon releasing new platform support for background autobuild.  I have been self-hosting on this for a few weeks, and one area that doesn't run very smoothly is launching.  Here is one scenario: 

- Autobuild is on, background build enabled. 
- User starts a background CVS checkout operation.  Say it's a slow connection and it takes a few minutes. 
- While waiting, the user continues to do some work, modifying and saving a java file 
- The save operation completes because it is orthogonal to the checkout (operating on disjoint set of resources) 
- The subsequent build cannot proceed, because building requires write access to all projects 
- The user then launches a debug VM that involves the changed class 
- Since the build has not run, the launched VM will operate on stale .class files 

One possible solution is to wait for the auto-build to complete before launching.  This can be accomplished using the job manager's join method, which allows a thread to join a running job: 

Platform.getJobManager().join(ResourcesPlugin.FAMILY_AUTO_BUILD, null); 

The problem is, this will now block the launch from proceeding, possibly for several minutes until the checkout completes.  A fancier solution would be to detect that the auto-build is blocked, and then give the user the option to proceed anyway.  You can determine that a job is blocked by seeing if it is in the waiting state (this is pseudo-code, I haven't test it): 

Job[] build = Platform.getJobManager().find(ResourcesPlugin.FAMILY_AUTO_BUILD); 
if (build.length == 1) { 
   if (build[0].getState() == Job.WAITING) { 
       //auto-build is blocked by another process, so ask the user if they want to launch or wait 
   } else if (build[0].getState() == Job.RUNNING) { 
       //auto-build is running, so join it to wait until it completes 
      build[0].join(); 
   } 
} 

That way the user can choose to launch without building.  If they know they have not made any changes that will affect the running program, they will want to proceed without waiting. 

Let me know your thoughts on this. 

More info on the platform changes can be found here (doc timelines are outdated): 

http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/plan_concurrency_listeners.html 

Background build can currently be enabled with the following debug .options: 

org.eclipse.core.resources/debug=true 
org.eclipse.core.resources/build/background=""> 

(background build is broken in I20030916, but should be fixed for tomorrow) 

John.