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.
Created attachment 140359 [details] log file 1. Install NetBeans 7.4 RC1 or delete userdir and cachedir. 2. Create new Maven POM project. 3. Downloading Archetype is stuck and won't go away. First time I restarted NetBeans and it still happened when I created another new project. After that, every time I delete the userdir and cachedir, this happens first time but works after the first restart. Product Version: NetBeans IDE 7.4 RC1 (Build 201309162201) Java: 1.8.0-ea; Java HotSpot(TM) 64-Bit Server VM 25.0-b50 Runtime: Java(TM) SE Runtime Environment 1.8.0-ea-b108
Downloading Archetype apparently covers indexing the local repository the first time around. We add the archetype to local repo to be able to find it in the list of all archetypes. But I think in 7.4 (or 7.3) the list of archetypes from index was replaced by list of archetypes from archetype-catalog.xml files. (in local/remote repository roots) http://hg.netbeans.org/core-main/rev/f1801de319ee indexing is skipped when there is no index is present during deleteArtifact() and updateArtifact() calls. still a bit curious why this is happening as the code is still almost the same as when issue 154913 was fixed.
verified in Product Version: NetBeans IDE 7.4 (Build 201310111528) Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18 System: Mac OS X version 10.9 running on x86_64; UTF-8; en_US (nb) User directory: /Users/tomas/Library/Application Support/NetBeans/7.4 Cache directory: /Users/tomas/Library/Caches/NetBeans/7.4
Unfortunately, this seem to still randomly occur, even if initial indexing of local repo does not happen.
(In reply to Tomas Danek from comment #3) > Unfortunately, this seem to still randomly occur, even if initial indexing > of local repo does not happen. can you be more specific here? we skip the update of index when we believe that the index is not there yet. if (!loc.exists() || !new File(loc, "timestamp").exists() || !IndexReader.indexExists(new SimpleFSDirectory(loc))) { I can imagine scenarios when there's a false positive however even in that case we only supposed to add the artifacts related to current build.
it's not actually random. 1. the downloading task is triggered when maven coordinates panel is used. depending on how long you stay in that panel, the progress bar will either be shown or not. 2. the indexing of the archetype was correctly skipped the first time (on each IDE startup) but later on it went on, could have been eventually delayed by the indexing going on through other means. not a patch candidate after all, fix will be more complex.
http://hg.netbeans.org/core-main/rev/e1dea0c7d546 http://hg.netbeans.org/core-main/rev/32076a263f60
http://hg.netbeans.org/core-main/rev/1f233e7a4a93 attempt to prevent duplicate finish calls one way, the other way is still open and causes stuck progress bars. I've reverted the workaround due to issue 241656 and passing on to progress for evaluation
Integrated into 'main-silver', will be available in build *201402140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/1f233e7a4a93 User: Milos Kleint <mkleint@netbeans.org> Log: #236251 more attempts to tackle the stuck progress bar
I have the same problem on JDK 7.51 and Windows XP SP3 32 bit.
Still present in 8.0 FCS.
Problem seems to have been fixed in: Product Version: NetBeans IDE 8.0.2 (Build 201411181905) Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 2 Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 and Product Version: NetBeans IDE Dev (Build 201509170002) Java: 1.8.0_60; Java HotSpot(TM) 64-Bit Server VM 25.60-b23 Runtime: Java(TM) SE Runtime Environment 1.8.0_60-b27 System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)