1. Deploy several versions of a GA to a hosted Maven 2 repo in repo 2.14.13
2. Use the Standard UI Upgrade Wizard to directly migrate from Repo 2 to Nexus Repo 3.38.1 or greater using hard link, include the hosted repo from in step 1.
3. Download using HTTP GET the GA maven-metadata.xml file from repo 3. Capture and make note the response header value of "Last-Modified"
4. Deploy a new version of the GA to Nexus Repo 3 to the same hosted repo name under test. Use mvn deploy:deploy-file goal for this ( which uses standard Maven PUT requests and explicitly uploads a new maven-metadata.xml file )
5. Download again using HTTP GET the GA maven-metadata.xml file from repo 3 hosted repo. Capture and make note the response header value of "Last-Modified".
- the Last-Modified header in step 5 returns the same value as that recorded in Step 3 - NOT EXPECTED
- the content of maven-metadata.xml from step 5 does include the new deployed version
- the blob-updated date in the UI Browse view for the maven-metadata.xml does reflect the modification time from when the new version was deployed
- the "last_modified" time for the maven-metadata.xml asset in the browse UI still reflects the time of original creation of the maven-metadata.xml file during migration in step 2
- an HTTP conditional GET sent to Repo 3 with "If-Modified-Since" header with the value of last-modified header returned in step 3 returns a 304 Not Modified in step 5 - NOT EXPECTED
The reproduce steps described above are very specific to versions of products and migration settings, however at time filing not all product versions released since have been tested. ie. The scope of this bug may not only be limited to the versions and scenario described.
Also, this bug can prevent a Maven 2 Proxy repository ( like in another Nexus Repo instance) from successfully downloading new maven-metadata.xml files updated at a hosted repo in the affected repo 3 versions.
1. When the content changes of a maven-metadata.xml ( or any repo content for that matter), then the last modification time must also reflect the actual modification time for the returned content
2. Conditional GETs and HEAD requests using HTTP cache headers like If-Modified-Since that rely on last modified time MUST WORK.
3. when a last-modified header is returned, it must reflect the actual time the served metadata was generated.
One must use the browse view in the UI to navigate to the maven-metadata.xml asset affected in repo 3, delete that asset, THEN use the scheduled task to rebuild the metadata for that specific GA affected, using the fields for the group id and artifact id in the task.
Using the rebuild maven metadata task ONLY will not help this issue ( though it should).