This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Nb7.6 build 200904131401 I find that project scanning is very frequent and performance intrusive. Every 2nd or third time i open the same group of maven projects i end up waiting for about 7 min for scanning projects.. to finish. It looks like it scans local maven repo, my projects, jdk rt.jar etc... I don't understand why so frequently. I would accept that first time project can potentially take long time as it needs to learn about the project structure. I can see that this can become very painful as more dependencies are introduces and more projects are added. It's rescanning way to often or the process is too much of a performance drain maybe someone can set my expectation strait here, but i feel it a legitimate concern.
Created attachment 80076 [details] netbean scanning maven projects
Just want to emphasize on the duration and speed as well, i just compared this operation with Netbeans 6.5, nb6.5 is much better and faster at loading and scanning maven projects. So right now as it stands in NB6.7 it's definitely a step backward in term of performance. I am also attaching a heap trace during scanning. What really strikes me JaxWsOpenHook$WebservicesChangeListener.updateJaxWs() is taking so much time. In my case I find this feature dead wrong, please don't touch my jaxws configurations i use CXF and i configure everything with spring. I raised other issues with this feature, i wish someone would pull this feature out.
Created attachment 80090 [details] during scanning
reassigning to java for evaluation of repeated scanning. I've noticed the same and often the error marks stay even though they shuld disappear and single files get rescanned upon opening.. as far as I can tell the jaxws open hook is only waiting for teh scanning to finish and is not performing any tasks on it's own. mkuchtiak: please evaluate the jaxws part of the issue. I've noticed you have spawned a req. processor job for each project and there's like 10+ running concurrently. Maybe you should create your own RP queue and put the jobs there..
You hit it right on the nail with the error marks. I was embarrassed by this already in front of another developer. I Introduced him to Netbeans Opened all projects, build it and deployed in on server, he saw me do it all. But i could not explain to him why on almost all projects, netbeans is showing error marks even thought maven built and deployed. I had to shutdown netbeans and bring it back up, explaining these error marks are out of synch. Sometimes the restart would not alway be effective. For a new user, this a nightmare because they are not sure if they coded something wrong, or is the IDE getting confused.
Just want to add, that the error marks also are out of synch even in Netbeans 6.5 as far as maven is concerned.
can we get this fixed in 6.7 timeframe? I consider it crucial to the success of maven support in 6.7. There have been problems of this kind since forever, for some reason they are more common for maven projects (my suspicion is the deep directory structure of the local repository). It might get overlooked in simple setups, but any non-trivial real life project suffers from it time to time. Can we increase to P2?
@all: Do you have any reproducible scenario? If not this is really hard to fix this issue. @mkleint: I don't think this issue is correct candidate for P2. But we can discuss this.
Ok, I see two issues here - (a) scanning performance (unneeded/unexpected/? scanning) and (b) stale error badges. For the first one could you please run the IDE with -J-Dorg.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.level=FINE and attach the IDE's log file (<ide-userdir>/var/log/messages.log) here. That should show us what was the IDE indexing and perhaps we we will the be able to guess why. In general scanning is always done when a project is opened (ie IDE started), but it should not take too long _if_ nothing changed since the last time the scanning ran. So for example just opening/closing projects or restarting the ide _without_ any changes in files on your disk (timestamp check) the initial scanning should be fast as it only needs to check that nothing really changed. On the other hand if for _any_ reason local files changed (eg. you run a build, update repo, download new versions of your libraries, etc) the scanning will have to physically reindex all the changed stuff. And it may take some time. Finally, the indexing was under heavy development in Nb6.7 and we are still fixing bugs. Please always use recent dev builds for testing/verifying problems/fixes. Thanks As for (b) stale error badges - Milos demonstrated the problem on a simple testcase and we are looking into it. Thanks Milos
Created attachment 80264 [details] First start up - no source changes
Created attachment 80266 [details] Restart the IDE with the same project group then scanning begins for long time
I've implemented some improvement in @WebService annotation processing. See: http://hg.netbeans.org/main?cmd=changeset;node=50b123a52883
Well this issue definitely has bent my will to work on our projects with the latest build. Other issues were manageable ,i could still get a lot of work done. But this one had me change back to NB6.5. I will try newer builds later see it this improved.
Just Tried build NB6.7 200904210201 I start the IDE load all 14 maven projects. Let it scan for the first time. ( takes about 12min). Wait so that it's done Restart the IDE and now have to wait again for scanning to be over. Also really long time. I thought of something funny. If you guys had to develop the entire netbeans modules using maven nb integration instead of ant. I wonder how long would you have to wait every you opened The IDE. (Days perhaps ?)
NB6.7 200905130201 Seems to work very well in respect to project scanning. The Initial long over 10 min scan is gone. I am really happy about that. Great progress.
ad a. scanning performance - thanks for your testing and confirmation that things have improved. The main slowdown was due to problems described in issue #162706 (fixed). ad b. error badges - there were several problems in checking classpath dependencies and rescanning affected roots, the main relevant to this was probably issue #163385 (fixed). So, this should now behave better, but there are still number of problems with error badges in general (most of them not introduced in 6.7 and unlikely to get fixed in 6.7), please see the umbrella issue #121950 and its dependencies.