Created attachment 74560 [details]
Attaching screen cap of task scanning

Reassigning to java for evaluation.

Perhaps because of slow network disc access I guess. Not sure, you didn't add some useful additional information.
Try to describe your environment in maximum detail. (OS, number of projects and their size), usage of NFS, messages.log etc.

This happens to me also on Windows XP, jdk 1.6.0_11. I had to uninstall the Task List plugin to make netbeans 6.5 usable
for me. I only had 3-4 smallish projects without a lot of dependencies and it took several minutes to complete task
scanning. All projects were on the local hard drive, no network file systems were involved in the projects.

This was a very vanilla install of netbeans on a windows computer. This problem made usage of netbeans out of the box
unusable without deinstallation of the plugin. IMO, this will really hurt the adoption chances of netbeans.

Thanks for your report. I am trying to reproduce it, but I am not very successful. I have several questions:
1) how many tasks you see in your Tasklist?
2) have you changed Task List settings? For example, have you changed Task List Filter?
3) Do you use one JDK for all your projects?

Thanks.

Having the same problem on a very large php/html project (several hundred files). Tasklist settings have not changed
from the default installation. No idea how many tasks the tasklist manager might find, as it is the first time I
attempted to open that project.  After a few seconds, the UI became unresponsive, and the nbexec job had to be killed at
the OS level.

There's a test case for this in http://www.netbeans.org/issues/show_bug.cgi?id=134990 (Apr 28)

I've done some more testing of where things get ugly, by taking some dependencies which I had identified as libraries,
to instead be on projects so that the output of the project build would be used as the dependency, instead of the
library jar file which would be copied into place as part of the library project build.

It looks to me like this is a workaround.  I still feel like the problem is that freeform projects have basically no
tracking built into them.  It seems to me that there could be an easy path from a library jar to a project by allowing a
library to have a path designation that is the "project" that builds that library.  I know that this is basically
covered by switching from a library to a project dependency as exists today.

However, my issue is that I always want to build against the production library build, no matter who built that library
for several of my libraries, so I really don't know how to address the async update issue of that library without being
able to say this library comes from this project.  You can already say this library comes from these sources, and it is
already the case that only one project can include a source tree, so that might be the dependency that needs more
inspection at the moment that the library is detected as updated, and then NB could find exactly what had changed.