See URL; nexus.index.last-incremental=0 so whenever the IDE wants to check for new content, it has to download the 2.2Mb index from scratch. http://www.sonatype.com/people/2009/05/nexus-indexer-20-incremental-downloading/ talks about how this can be avoided. I don't know the technical details of how you set up incremental publishing but we need to do it.
Please evaluate : if you do not plan to fix it for NB 7.0 ask for waiver ASAP.
This is probably fixed now with the new indexing script, though we will not know it is really working until the _next_ upload. Anyway this is not something to be changed in NB source code (it is just an RE process) so "fixing in 7.0" is meaningless.
added NO70 and also please confirm this is already fixed - thanks in advance.
Again, cannot verify that it is fixed until the next official upload to the repo, which would I guess be 7.0 FCS.
With RELEASE70 artifacts published, I _think_ this is working - at least, there is both a nexus-maven-repository-index.gz and a nexus-maven-repository-index.1.gz as expected. The former does include RELEASE70; I suppose the idea is that a fresh download just gets the n-m-r-i.gz, expecting it to be comprehensive, and ignores any incremental indices; whereas n-m-r-i.1.gz exists for the benefit of clients who downloaded n-m-r-i.gz after RELEASE70-BETA2 was published and now need to add information about RELEASE70.
If that is right, then the next publishing (RELEASE701?) will result in n-m-r-i.gz having everything from RELEASE65 through RELEASE701, n-m-r-i.1.gz with RELEASE70, and n-m-r-i.2.gz with RELEASE701.
Difficult to verify since you would need to have actually downloaded the index prior to RELEASE70 being published, then ask to refresh the index and verify that (1) just n-m-r-i.1.gz was downloaded, e.g. using Wireshark; (2) the result is complete. I do not have such a local index handy; perhaps someone on CC does.