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.
Netbeans 7.0 RC1 Java build 1.7.0-ea-b135 (64-bit) When I try opening a Maven project Netbeans hangs with a modal "opening project" dialog. I also noticed it is downloading a lot of data, probably the Maven repository index, but there is no visual indicator for this. A few minutes later I terminated the process because nothing seemed to be happening. Please see messages.log which I have attached.
Created attachment 107563 [details] messages.log
Could you please generate thread-dump once IDE hangs, attach it here and reopen? Also would be nice to know whether you are able to reproduce it regularly? Thanks in advance. http://wiki.netbeans.org/GenerateThreadDump
This issue is reproducible 100% of the time. I will attach the thread-dump and messages.log you requested.
Created attachment 107584 [details] thread dump
EndorsedClassPathImpl.getResources should not block on the indexer. Even though it uses RepositoryQueries.loadedContexts to examine only repositories which have already been indexed, this could block if that particular repository is currently being reindexed. I am not really sure what the fix should be, since the boot CP information is really needed when the project is opened. Could just report the target/endorsed/*.jar in the boot CP initially, then fire a change later when the index becomes available (and just hope the user does no clean build in the meantime), but this will cause "churn" in the scanner. And there is no way to tell whether another thread is currently holding the mutex without actually trying to acquire it (Mutex supports no such API); would need to rewrite the locking system to use java.util.concurrent. Even that is subject to some race conditions unless a new API is introduced to run queries on just those repos with an up-to-date index not currently being reindexed - a risky fix. Workaround should simply be to make sure all your repository indices are up to date before opening these projects. Or just wait for the reindexing to complete (and install a repository manager to avoid waiting for remote network connections in the future).
*** Bug 197525 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > Could just > report the target/endorsed/*.jar in the boot CP initially, then fire a change > later when the index becomes available (and just hope the user does no clean > build in the meantime) Better would be to ignore endorsed JARs initially, and post a task to check the loaded indices (or maybe all indices?) in a background thread, firing a change at the end - with the new endorsed CP containing either target/endorsed/*.jar or the corresponding repo entry. Still suffers from CP churn issue, but I guess that is the lesser of two evils.
core-main #66903d8faa69
Integrated into 'main-golden', will be available in build *201104120401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/66903d8faa69 User: Jesse Glick <jglick@netbeans.org> Log: #197510: EndorsedClassPathImpl.getResources blocked on repo indexer Check for repo analogues of target/endorsed/*.jar in a background thread only.
*** Bug 197652 has been marked as a duplicate of this bug. ***
I believe this issue is still not fixed. Product Version: NetBeans IDE 7.0 (Build 201104080000) Java: 1.6.0_25; Java HotSpot(TM) 64-Bit Server VM 20.0-b11 System: Windows 7 version 6.1 running on amd64; Cp1252; en_CA (nb) I will attach messages.log and a thread dump.
Created attachment 108295 [details] thread dump
Created attachment 108296 [details] messages.log
Hi Gili, no, this is not fixed in the NB 7.0 release, it is only fixed in the post-7.0 codeline. Can you please try out the trunk development builds? http://bits.netbeans.org/download/trunk/nightly/ Also, this bug is marked as a 70patch_candidate, so it may be addressed in the nearest patch for 7.0.
Right, the fix is not in 7.0. If it is verified and a backport to release70_fixes is requested then I will do that backport.
*** Bug 198607 has been marked as a duplicate of this bug. ***
Tomas, I know you are busy with something else, but could you please verify this issue, so we will fix it for Patch 1 ? Thanks in advance.
(In reply to comment #18) > Tomas, > I know you are busy with something else, but could you please verify this > issue, so we will fix it for Patch 1 ? Thanks in advance. Sure, this one occurred quite often for me in 7.0, i can try current dev build.
tried to reproduce in recent 7.0.1dev build, and it seems to be really fixed -> verified.
The fix is merged into release70_fixes as changeset: 198556:72d5fbebf7cb http://hg.netbeans.org/releases/rev/72d5fbebf7cb The module specification number was already increased by changeset 4bba1140ade6.
did not reproduce in patch 1.