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 7.0 Beta (Build 201011152355) VM: Java HotSpot(TM) 64-Bit Server VM, 19.0-b09, Java(TM) SE Runtime Environment, 1.6.0_23-b05 OS: Windows 7 Stacktrace: java.io.FileNotFoundException: C:\Users\Gabriele\.netbeans\7.0beta\var\cache\mavenindex\local\_78_1.del (The system cannot find the file specified) at java.io.RandomAccessFile.open(RandomAccessFile.java:0) at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput$Descriptor.<init>(SimpleFSDirectory.java:78) at org.apache.lucene.store.SimpleFSDirectory$SimpleFSIndexInput.<init>(SimpleFSDirectory.java:108) at org.apache.lucene.store.SimpleFSDirectory.openInput(SimpleFSDirectory.java:65) at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:691)
Created attachment 104820 [details] stacktrace
*** Bug 194154 has been marked as a duplicate of this bug. ***
Some sort of unreproducible issue with your Maven repository index, I guess. No idea how to reproduce. Maybe could try to recover from such things by discarding the existing index. Workaround would be to delete C:\Users\Gabriele\.netbeans\7.0beta\var\cache\mavenindex\local.
Created attachment 104956 [details] stacktrace
could be related to https://jira.codehaus.org/browse/MINDEXER-52 like issue 204706
updateIndexWithArtifacts() method is now protecting all access to indexer codebase by a lock from DefaultIndexingContext. http://hg.netbeans.org/core-main/rev/08a93fe0f8da the idea is to synchronize access to internal resources with the thread spawned by indexer codebase which manipulates the index. closing as fixed under assumption that the problem encountered was caused by the concurrent access to resources without both parties using the same locking mechanism.
*** This bug has been marked as a duplicate of bug 204706 ***
Jesse, I intentionally marked the issue as fixed, not duplicate, as we don't really know it's a duplicate and if one or more of the issues resurface in 7.2 I don't want to handle all the problems within one issue..
We do not really know it was fixed either; we just surmise that it had the same root cause, and is thus a duplicate. If one of the exceptions, but not others, resurfaces then we would reopen just that issue - it would not then matter what its original resolution was.