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.
Goes from websvc.design to o.n.upgrader only. Something to do with NexusRepositoryIndexerImpl.repeatedFlatSearch I guess, but even BooleanQuery.setMaxClauseCount(Integer.MAX_VALUE) does not seem to help. http://bits.netbeans.org/maven2/org/netbeans/modules/ shows that the displayed modules are just the last 79 out of 685. Not sure if it is the index that is broken or the query, but I think the query; for example, Search on "utilities.project" correctly displays org.netbeans.modules:org-netbeans-modules-utilities-project.
Tomas any idea? I would expect to get either full results or no results, but instead am getting the tail end of the results.
I will look at it under debugger. It's enough to do a query in Maven Repository Browser Containing Text: org.netbeans.modules to demonstrate the problem?
Searches may work, or may turn up different problems. The problem I found can be reproduced merely by expanding the group node (path as given in bug summary). org.netbeans.api also affected.
I have a fix but want a peer review. Maven Indexer behaves strangely with respect to a hit limit parameter that I was not aware existed, and org.netbeans.api and org.netbeans.modules groups both contain >1000 artifacts thus triggering this problem.
core-main #106ac2980f1f
It's the best you can do with such a strange API as the maven's AbstractSearchRequest is. The setResultHitLimit is undocumented but in the source code is written: "The limit size, the maximum possible count of items in response. Different than count above, since if this set, and the search funds more then this number, the response will be _empty_ and a flag will be set on response about this." Which is a bit different from what it's doing it returns the 1000 (UNDEFINED_HIT_LIMIT) items. The restart of the query may take some time, but the index should be "hot", it should not be a problem. The patch seems good to me.
Maybe in the future we can try to use DefaultSearchEngine.searchIteratorPaged. If the returned iterator is implemented as load on demand it should not have such problems. But I didn't look how it's implemented yet.
Integrated into 'main-golden', will be available in build *201103280400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/106ac2980f1f User: Jesse Glick <jglick@netbeans.org> Log: #197036: Maven Repositories > NetBeans > org.netbeans.modules shows truncated list
(In reply to comment #7) > Maybe in the future we can try to use DefaultSearchEngine.searchIteratorPaged. Would be useful anyway, to minimize transient memory usage. > If the returned iterator is implemented as load on demand it should not have > such problems. According to comments in upstream report it does in fact suffer from the same bug.
verified in trunk, full list is shown. You can integrate into release70.
releases #be2b0c856305
verified in 7.0 Product Version: NetBeans IDE 7.0 RC1 (Build 201103300000) Java: 1.6.0_24; Java HotSpot(TM) 64-Bit Server VM 19.1-b02-334 System: Mac OS X version 10.6.7 running on x86_64; MacRoman; en_US (nb) Userdir: /Users/tomas/.netbeans/7.0rc1
*** Bug 197813 has been marked as a duplicate of this bug. ***