| Showing accurate progress of project builders [message #303016] |
Fri, 05 May 2006 10:43 |
Eclipse User |
|
|
|
I've been trying to improve the user feedback of progress during an auto
build with a custom builder (the AspectJ builder in AJDT), but I seem to
have hit limitations in the way the build manager works, which affects
all builders. The goal here is for the user to make a change in a
project and save, triggering an auto build, and for the progress of the
job to go as smoothly as possible from 0% to 100%.
Say I have 10 projects in my workspace (such as regular Java projects),
and I do a clean / rebuild of one of them - one which is unrelated to
any of the others. Instead of progress for the auto build job going from
0% to 100% it goes from something like 30% to 40%. This is because
BuildManager.basicBuildLoop() in org.eclipse.core.resources calls the
builder for ALL projects in the workspace, dividing the total work units
for the progress monitor between them. Therefore the other projects are
given 90% of the work units, yet those projects have no changes so take
almost no time to process, leaving just 10% for the project actually
being built. Depending on the project build order, this 10% of "real
work" will occur somewhere amongst the 90% of almost "no work".
Now say the project in question is a PDE project, which will have two
PDE builders associated with it, in addition to the Java builder (or in
my case the AspectJ builder). The progress monitor work units for
building the project therefore get split up for each of the separate
builders. This means I only get about 3% in which to show the progress
of my builder, despite the builder taking something like 99% of the
total execution time. So the user sees the progress jump almost
immediately to some arbitrary value, then move a tiny amount somewhat
slowly (assuming a big project!), then suddenly jump the rest of the way.
Showing meaningful progress is hard, but surely we can do better than
this? The current mechanism simply doesn't scale to large workspaces,
with projects having potentially many builders. Can anyone think of
anything that could be done in the context of an individual builder to
improve matters? Failing that, improvements to the build manager would
be required - for example it would need to determine upfront how many
projects are actually going to build, which would I think require a fair
amount of restructuring. Any other thoughts/comments?
Regards,
Matt.
|
|
|
Powered by
FUDForum. Page generated in 0.07215 seconds
Home