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.

Bug 191685

Summary: Publishing incremental Nexus index
Product: www Reporter: Jesse Glick <jglick>
Component: Builds & RepositoriesAssignee: pgebauer <pgebauer>
Status: RESOLVED FIXED    
Severity: normal CC: anebuzelsky, mmirilovic
Priority: P2    
Version: 7.0   
Hardware: All   
OS: All   
URL: http://bits.netbeans.org/maven2/.index/nexus-maven-repository-index.properties
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 197039    
Bug Blocks:    

Description Jesse Glick 2010-11-05 18:39:46 UTC 
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.
Comment 1 Marian Mirilovic 2011-03-25 23:17:23 UTC 
Please evaluate : if you do not plan to fix it for NB 7.0 ask for waiver ASAP.
Comment 2 Jesse Glick 2011-03-28 19:24:43 UTC 
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.
Comment 3 Marian Mirilovic 2011-03-30 21:52:02 UTC 
added NO70 and also please confirm this is already fixed - thanks in advance.
Comment 4 Jesse Glick 2011-03-30 22:06:56 UTC 
Again, cannot verify that it is fixed until the next official upload to the repo, which would I guess be 7.0 FCS.
Comment 5 Jesse Glick 2011-04-21 12:29:15 UTC 
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.