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.
Build: NetBeans IDE Dev (Build 200908022240) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Windows XP, 5.1, x86 User Comments: vargas: The [surefire:test] phase when building a maven project is way way slow, almost freezes my box Maximum slowness yet reported was 39016 ms, average is 39016
Created attachment 86955 [details] nps snapshot
the snapshot shows long execution time in native getCanonicalPath() when invoking MavenFileOwnerQueryImpl - maybe some file is on a remote server? reassigning to maven team
Build: NetBeans IDE Dev (Build 200909151512) VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08 OS: Windows XP, 5.1, x86 User Comments: starting a freshly downloaded nightly build while an svn update was running in the background. 5 fairly large maven projects were automatically opened. Maximum slowness yet reported was 39016 ms, average is 18798
Created attachment 87770 [details] nps snapshot
the first snapshot seems to be trash due to above mentioned reasons. the second one is unrelated to the original problem. It deals with AWT reaching for project's lookup while it's being constructed along with the maven project model in another thread. I suppose the svn update also plays a role in the situation as it's possibly changing the metadata for maven projects, firing changes. There is no way to speed up the processing that I can see. 1. it's the maven project loading that takes time. It can download stuff from internet, it will load and parse heaps of xml files. 2. only the first loading of the maven project is risky, any subsequent loading will only replace the currently active instance after being completely loaded (and firing change events for everyone to refresh) 3. it has to be done on first request only and not at nb project instance creation time as the nb project instances are many and only a handful eventually need the maven project resolved. => so there is a time slot at first loading of a maven project in non-AWT thread, which can block AWT if it requires project lookup or the maven project instance during the time the instance is being loaded. There is no way around that I can see. It will be significant to projects that are not completely resolved (eg. newly checked out, unbuilt or svn updated projects). On average the AWT thread will only be blocked half the time of the loading, often non-occuring or unnoticable. maven embedder 3.x is supposed to be faster on project resolution, but obviously the time spent in network traffic will stary the same. -> LATER
This issue already has 5 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157711
Build: NetBeans IDE Dev (Build 200908022240) VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.18-164.el5xen, i386 User Comments: Maximum slowness yet reported was 39016 ms, average is 15473
Created attachment 89020 [details] nps snapshot
This issue already has 6 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=157711
NetBeans.org Migration: changing resolution from LATER to WONTFIX