Bug 45071

Comment 1 Timothy Halloran 2003-10-16 22:06:23 EDT

Created attachment 6460 [details]
Builder class code that causes this problem

Here is the class that is having the problem...sadly this is not a very stand
alone case but it might be useful to determine the problem.  If there is
interest I could try to scale it down into a standalone plugin to see if a
smaller example manefests the problem.

Comment 2 Nick Edgar 2003-10-17 11:48:18 EDT

From the UI's point of view, we just ask core to do an operation (e.g. a build, 
or an operation like save which triggers an incremental build) and pass a 
progress monitor for it to talk to.

Breaking up of the overall progress for the sub-operations, including running 
multiple builders, is Core's responsibility.

Comment 3 Timothy Halloran 2003-10-17 12:02:09 EDT

The above implies that there is some sort of builder protocal for the
IProgressBar that I'm not saavy of -- and am messing up.

It looks like the builder "driver" (core?) is breaking it up into equal
divisions for each registered builder that is invoked -- but how does a builder
author communicate progress when the increment aloted is unknown?

Comment 4 Nick Edgar 2003-10-17 12:25:41 EDT

You shouldn't need to worry about it.  You should be able to call beginTask, 
subTask, worked, etc. as if you had 100% of the progress monitor to yourself.  
Core passes a SubProgressMonitor to the builder with the appropriate percentage 
of the overall work allocated to it.

Comment 5 John Arthorne 2003-10-17 13:40:58 EDT

What makes you believe that worked(1) does nothing?  I ask because there is no
definite side-effect of this call in normal usage.  To explain further, the
complete progress monitor is divided into segments: one per builder per project.
 If there are, say, 10 projects with three builders on each, then each builder
gets 1/30th of the entire progress bar.  There are only a fixed number of
visible increments on the progress widget.  The portion allocated to your
builder may not span many visual increments. So, you may call worked(1) a
thousand times, but the bar may only actually move twice during that period.

Try running your builder on a single project without only the java builder and
your builder.  Your builder should get half of the visible progress bar in this
case.  I tried a quick example with a simple builder after the java builder, and
the progress indicator looked fine.  Here was my builder code:

protected IProject[] build(int kind, Map args, IProgressMonitor monitor) throws
CoreException {
	monitor.beginTask("Builder two is working", 1000);
	for (int i = 0; i < 1000; i++) {
		monitor.worked(1);
		try {
			Thread.sleep(10);
		} catch (InterruptedException e) {
		}
	}
	monitor.done();
	return null;
}

Comment 6 Timothy Halloran 2003-10-17 14:08:42 EDT

Interesting, I was doing much the same, see the code below:

package progressbuilderbug;

import java.util.Map;

import org.eclipse.core.resources.IProject;
import org.eclipse.core.resources.IncrementalProjectBuilder;
import org.eclipse.core.runtime.CoreException;
import org.eclipse.core.runtime.IProgressMonitor;

public final class Majordomo extends IncrementalProjectBuilder {

  /**
   * @see org.eclipse.core.internal.events.InternalBuilder#build(int,
java.util.Map, org.eclipse.core.runtime.IProgressMonitor)
   */
  protected IProject[] build(int kind, Map args, IProgressMonitor monitor)
    throws CoreException {
    monitor.beginTask("pbBuilder", 1000);

    for (int i = 0; i < 1000; i++) {
      monitor.worked(1);
      monitor.subTask("On number " + i);
      if (i % 10 == 0) {
        try {
          Thread.sleep(500);
        } catch (InterruptedException e) {
          //@ignore
        }
      }
    }
    return null;
  }

}
------------------------------

However, this gives me some insight into whats going on.

(1) Your description is correct -- however CORE does not appear to notice what
Java projects are opened and what ones are closed

  -- When I have only one project existing/opened; I get half the space with the
Java builder (with my demo program above; haven't tried the big one yet)
  -- When I have three projects existing: 1 opened 2 closed...my builder and the
Java builder get 1/6 of the progress bar -- the remaining jumps at the end.

I'm on version 2.1.1 of Eclipse -- haven't tried this on M4

Thoughts?

Comment 7 John Arthorne 2003-10-17 14:17:40 EDT

Yes, we divide the work by the number of projects before computing whether the
projects are open (in both 2.1.1 and 3.0 M4).  We could possibly walk the list
twice, first computing the set of accessible projects, initializing the number
of work units, and then allocating work units only to open projects.

Comment 8 Timothy Halloran 2003-10-17 14:26:33 EDT

I think thats a good idea...Is there ever a case that a closed project has work
done on it by a builder?  If the answer is no then allocating space to closed
projects is misleading in the UI...Is this easy for you to fix?

Yes, it looks to me like 3.0M4 does the same thing (but unless I do a rebuild I
get the background build -- very cool by the way!!!)

I had 34 projects in my meta-eclipse in this case (all but one closed) and I
never got any indication of progress on Java or my builder -- hence I thought it
was broke (and my builder was causing it) because my main-eclipse only had 3
projects (all opened) and the progress bar worked fine :-)

Comment 9 John Arthorne 2004-05-27 10:26:06 EDT

Not for 3.0. Reassigning.

Comment 10 John Arthorne 2007-06-22 11:05:45 EDT

Not planning to address this.

Comment 11 John Arthorne 2009-06-12 11:46:19 EDT

*** This bug has been marked as a duplicate of bug 280053 ***