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

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

I disagree... If the user has a preference set to "build before launch", then they expect wait as the build completes. Only if the build has to be delayed for a unknown amount of time, is the wait unexpected. I don't think we want to pop up a dialog each time they launch saying "do you want to wait for a build?". The answer is,"yes - I checked the preference to do this".

Darin

Jared Burns <jaredburns@xxxxxxx> Sent by: platform-debug-dev-admin@xxxxxxxxxxx 09/16/2003 08:25 PM Please respond to platform-debug-dev

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

Just a nit, but I think we want to prompt the user anytime they're going to 
have to wait for a build to finish. Whether it's "waiting" or "running" 
doesn't matter to the user - it's an unexpected delay.

- Jared

On Tuesday 16 September 2003 05:38 pm, Darin Wright wrote:
> 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.

_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev