• nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST


    Novice nexus oss (2.0.0) user here – getting unexpected results when requesting v=LATEST artifact from our hosted repo. I am hoping someone could explain what is wrong with our maven-metadata.xml (or my expectations of what v=LATEST returns). We have an non-plugin JAR artifact “castanealabs-config” in Snapshots repo (published via maven-deploy-plugin, fwiw). The two most recent versions are 10-SNAPSHOT and 11-SNAPSHOT. The latter was published most recently (and has the highest version by maven convention, as I understand it). Yet Nexus REST API (/artifact/maven/{resolve,redirect}) keeps returning most recent snapshot of 10-SNAPSHOT instead when asked for v=LATEST.

    Why?

    What inputs (from maven-metadata.xml at /group/artifact/maven-metadata.xml) does API evaluate to arrive at 10-SNAPSHOT. API responses below; attached are  maven-metadata.xml  files for:

    1)      10-SNAPSHOT

    2)      11-SNAPSHOT

    3)      artifact

    Notice that in artifact’s maven-metadata.xml lastUpdated matches the timestamp of 11-SNAPSHOT. From reading Nexus FAQ, my understanding is that versioning/latest attribute in that file is irrelevant since this is a non-plugin artifact.

    Thank you,

    -nikita

    Asking /resolve for ‘v=LATEST’:

    $curl –uxxx:xxx -i "http://host/nexus/service/local/artifact/maven/resolve?g=com.castanealabs&a=castanealabs-config&v=LATEST&r=snapshots"

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:08:19 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>10-20120320.074835-5</version>

        <baseVersion>10-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>5</snapshotBuildNumber>

        <snapshotTimeStamp>1332229715000</snapshotTimeStamp>

        <sha1>f107b5dd710dc3dbac8029ecb3f394b265e7c078</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/10-SNAPSHOT/castanealabs-config-10-20120320.074835-5.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Now ask for 11-SNAPSHOT explicitly – notice more recent <version/>:

    $curl –uxxx:xxx -i "http://host/nexus/service/local/artifact/maven/resolve?g=com.castanealabs&a=castanealabs-config&v=11-SNAPSHOT&r=snapshots"

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:12:48 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>11-20120320.181629-2</version>

        <baseVersion>11-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>2</snapshotBuildNumber>

        <snapshotTimeStamp>1332267389000</snapshotTimeStamp>

        <sha1>d90c05740d587ae57fddd2318fc40258104283e2</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/11-SNAPSHOT/castanealabs-config-11-20120320.181629-2.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Maven-metadata.xml at /group/artifact/ level:

    <?xml version="1.0" encoding="UTF-8"?>

    <metadata>

    <groupId>com.castanealabs</groupId>

    <artifactId>castanealabs-config</artifactId>

    <versioning>

    <latest>10-SNAPSHOT</latest>

    <release></release>

    <versions>

    <version>1.0-SNAPSHOT</version>

    <version>7-SNAPSHOT</version>

    <version>8-SNAPSHOT</version>

    <version>10-SNAPSHOT</version>

    <version>11-SNAPSHOT</version>

    </versions>

    <lastUpdated>20120320181629</lastUpdated>

    </versioning>

    </metadata>


    --------------------------------------------------------------------- 
    To unsubscribe, e-mail: [hidden email] 
    For additional commands, e-mail: [hidden email]

     maven-metadata-10-SNAPSHOT.xml (907 bytes) Download Attachment
     maven-metadata-11-SNAPSHOT.xml (907 bytes) Download Attachment
     maven-metadata-artifact.xml (587 bytes) Download Attachment
    Reply | Threaded |   
    Selected post

    RE: nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Nikita Tovstolesonline

    Update: I observed the following:

    ·         Running ‘rebuild metadata’ on repository from nexus UI fixes the problem – specifically API responds to v=LATEST with newest version (11-SNAPSHOT in the case below)

    ·         The only change to maven-metadata.xml from the above is: <latest/> updated from 10-SNAPSHOT to 11-SNAPSHOT. So ‘latest’ does matter for non-plugin artifacts – contrary to the FAQ (http://bit.ly/GEurFo )?

    ·         The cycle repeats, however – after newer 12-SNAPSHOT is published, maven-metadata.xml still lists 11-SNAPSHOT as <latest/> (albeit listing lastUpdated matching 12-SNAPSHOT) and Nexus API responds with 11-SNAPSHOT when asked for ‘v=LATEST’

     

    So, seems like one of the following must be true:

    1)      Mvn deploy uploads incorrect maven-metadata.xml (and <latest/> does matter)

    a.       I ran mvn deploy against a local file repo, and the resulting maven-metadata.xml did not have <latest/> property at all (using mvn 3.0.4 and maven-deploy-plugin 2.7)

    2)      Nexus does something to maven-metadata.xml on upload and the resulting file has wrong <latest/>

    3)      <latest/> is indeed irrelevant and Nexus REST API returns wrong version for some other reason (can Nexus API be caching a response?)

     

     

     

    From: Nikita Tovstoles [mailto:[hidden email]
    Sent: Tuesday, March 20, 2012 5:25 PM
    To: [hidden email]
    Subject: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Novice nexus oss (2.0.0) user here – getting unexpected results when requesting v=LATEST artifact from our hosted repo. I am hoping someone could explain what is wrong with our maven-metadata.xml (or my expectations of what v=LATEST returns). We have an non-plugin JAR artifact “castanealabs-config” in Snapshots repo (published via maven-deploy-plugin, fwiw). The two most recent versions are 10-SNAPSHOT and 11-SNAPSHOT. The latter was published most recently (and has the highest version by maven convention, as I understand it). Yet Nexus REST API (/artifact/maven/{resolve,redirect}) keeps returning most recent snapshot of 10-SNAPSHOT instead when asked for v=LATEST.

    Why?

    What inputs (from maven-metadata.xml at /group/artifact/maven-metadata.xml) does API evaluate to arrive at 10-SNAPSHOT. API responses below; attached are  maven-metadata.xml  files for:

    1)      10-SNAPSHOT

    2)      11-SNAPSHOT

    3)      artifact

    Notice that in artifact’s maven-metadata.xml lastUpdated matches the timestamp of 11-SNAPSHOT. From reading Nexus FAQ, my understanding is that versioning/latest attribute in that file is irrelevant since this is a non-plugin artifact.

    Thank you,

    -nikita

    Asking /resolve for ‘v=LATEST’:

    $curl –uxxx:xxx -i "http://host/nexus/service/local/artifact/maven/resolve?g=com.castanealabs&a=castanealabs-config&v=LATEST&r=snapshots"

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:08:19 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>10-20120320.074835-5</version>

        <baseVersion>10-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>5</snapshotBuildNumber>

        <snapshotTimeStamp>1332229715000</snapshotTimeStamp>

        <sha1>f107b5dd710dc3dbac8029ecb3f394b265e7c078</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/10-SNAPSHOT/castanealabs-config-10-20120320.074835-5.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Now ask for 11-SNAPSHOT explicitly – notice more recent <version/>:

    $curl –uxxx:xxx -i "http://host/nexus/service/local/artifact/maven/resolve?g=com.castanealabs&a=castanealabs-config&v=11-SNAPSHOT&r=snapshots"

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:12:48 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>11-20120320.181629-2</version>

        <baseVersion>11-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>2</snapshotBuildNumber>

        <snapshotTimeStamp>1332267389000</snapshotTimeStamp>

        <sha1>d90c05740d587ae57fddd2318fc40258104283e2</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/11-SNAPSHOT/castanealabs-config-11-20120320.181629-2.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Maven-metadata.xml at /group/artifact/ level:

    <?xml version="1.0" encoding="UTF-8"?>

    <metadata>

    <groupId>com.castanealabs</groupId>

    <artifactId>castanealabs-config</artifactId>

    <versioning>

    <latest>10-SNAPSHOT</latest>

    <release></release>

    <versions>

    <version>1.0-SNAPSHOT</version>

    <version>7-SNAPSHOT</version>

    <version>8-SNAPSHOT</version>

    <version>10-SNAPSHOT</version>

    <version>11-SNAPSHOT</version>

    </versions>

    <lastUpdated>20120320181629</lastUpdated>

    </versioning>

    </metadata>

    Reply | Threaded |   
    Selected post

    Re: nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Stuart McCulloch-2online
    <base href="x-msg://11/">
    On 22 Mar 2012, at 11:48, Nikita Tovstoles wrote:

    Update: I observed the following:
    ·         Running ‘rebuild metadata’ on repository from nexus UI fixes the problem – specifically API responds to v=LATEST with newest version (11-SNAPSHOT in the case below)
    ·         The only change to maven-metadata.xml from the above is: <latest/> updated from 10-SNAPSHOT to 11-SNAPSHOT. So ‘latest’ does matter for non-plugin artifacts – contrary to the FAQ (http://bit.ly/GEurFo )?
    ·         The cycle repeats, however – after newer 12-SNAPSHOT is published, maven-metadata.xml still lists 11-SNAPSHOT as <latest/> (albeit listing lastUpdated matching 12-SNAPSHOT) and Nexus API responds with 11-SNAPSHOT when asked for ‘v=LATEST’
     
    So, seems like one of the following must be true:
    1)      Mvn deploy uploads incorrect maven-metadata.xml (and <latest/> does matter)
    a.       I ran mvn deploy against a local file repo, and the resulting maven-metadata.xml did not have <latest/> property at all (using mvn 3.0.4 and maven-deploy-plugin 2.7)
    2)      Nexus does something to maven-metadata.xml on upload and the resulting file has wrong <latest/>
    3)      <latest/> is indeed irrelevant and Nexus REST API returns wrong version for some other reason (can Nexus API be caching a response?)
     

    Nexus only modifies the Maven metadata for a given repository when you explicitly ask to rebuild it, otherwise it is left to Maven to update.

    However, Maven no longer updates the LATEST tag on deploy, see http://jira.codehaus.org/browse/MDEPLOY-103 and its linked issues.

     
     
    From: Nikita Tovstoles [mailto:[hidden email]
    Sent: Tuesday, March 20, 2012 5:25 PM
    To: [hidden email]
    Subject: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST
     
    Novice nexus oss (2.0.0) user here – getting unexpected results when requesting v=LATEST artifact from our hosted repo. I am hoping someone could explain what is wrong with our maven-metadata.xml (or my expectations of what v=LATEST returns). We have an non-plugin JAR artifact “castanealabs-config” in Snapshots repo (published via maven-deploy-plugin, fwiw). The two most recent versions are 10-SNAPSHOT and 11-SNAPSHOT. The latter was published most recently (and has the highest version by maven convention, as I understand it). Yet Nexus REST API (/artifact/maven/{resolve,redirect}) keeps returning most recent snapshot of 10-SNAPSHOT instead when asked for v=LATEST.
     
    Why?
    What inputs (from maven-metadata.xml at /group/artifact/maven-metadata.xml) does API evaluate to arrive at 10-SNAPSHOT. API responses below; attached are  maven-metadata.xml  files for:
    1)      10-SNAPSHOT
    2)      11-SNAPSHOT
    3)      artifact
     
    Notice that in artifact’s maven-metadata.xml lastUpdated matches the timestamp of 11-SNAPSHOT. From reading Nexus FAQ, my understanding is that versioning/latest attribute in that file is irrelevant since this is a non-plugin artifact.
     
    Thank you,
    -nikita
     
    Asking /resolve for ‘v=LATEST’:
     
    HTTP/1.1 200 OK
    Date: Tue, 20 Mar 2012 22:08:19 GMT
    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:08:19 GMT
    Content-Type: application/xml; charset=UTF-8
    Date: Tue, 20 Mar 2012 22:08:19 GMT
    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4
    Content-Length: 638
     
    <artifact-resolution>
      <data>
        <presentLocally>true</presentLocally>
        <groupId>com.castanealabs</groupId>
        <artifactId>castanealabs-config</artifactId>
        <version>10-20120320.074835-5</version>
        <baseVersion>10-SNAPSHOT</baseVersion>
        <extension>jar</extension>
        <snapshot>true</snapshot>
        <snapshotBuildNumber>5</snapshotBuildNumber>
        <snapshotTimeStamp>1332229715000</snapshotTimeStamp>
        <sha1>f107b5dd710dc3dbac8029ecb3f394b265e7c078</sha1>
        <repositoryPath>/com/castanealabs/castanealabs-config/10-SNAPSHOT/castanealabs-config-10-20120320.074835-5.jar</repositoryPath>
      </data>
    </artifact-resolution>
     
    Now ask for 11-SNAPSHOT explicitly – notice more recent <version/>:
     
    HTTP/1.1 200 OK
    Date: Tue, 20 Mar 2012 22:12:48 GMT
    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:12:48 GMT
    Content-Type: application/xml; charset=UTF-8
    Date: Tue, 20 Mar 2012 22:12:48 GMT
    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4
    Content-Length: 638
     
    <artifact-resolution>
      <data>
        <presentLocally>true</presentLocally>
        <groupId>com.castanealabs</groupId>
        <artifactId>castanealabs-config</artifactId>
        <version>11-20120320.181629-2</version>
        <baseVersion>11-SNAPSHOT</baseVersion>
        <extension>jar</extension>
        <snapshot>true</snapshot>
        <snapshotBuildNumber>2</snapshotBuildNumber>
        <snapshotTimeStamp>1332267389000</snapshotTimeStamp>
        <sha1>d90c05740d587ae57fddd2318fc40258104283e2</sha1>
        <repositoryPath>/com/castanealabs/castanealabs-config/11-SNAPSHOT/castanealabs-config-11-20120320.181629-2.jar</repositoryPath>
      </data>
    </artifact-resolution>
     
     
    Maven-metadata.xml at /group/artifact/ level:
    <?xml version="1.0" encoding="UTF-8"?>
    <metadata>
    <groupId>com.castanealabs</groupId>
    <artifactId>castanealabs-config</artifactId>
    <versioning>
    <latest>10-SNAPSHOT</latest>
    <release></release>
    <versions>
    <version>1.0-SNAPSHOT</version>
    <version>7-SNAPSHOT</version>
    <version>8-SNAPSHOT</version>
    <version>10-SNAPSHOT</version>
    <version>11-SNAPSHOT</version>
    </versions>
    <lastUpdated>20120320181629</lastUpdated>
    </versioning>
    </metadata>
     
     
     
     

    Reply | Threaded |   
    Selected post

    RE: nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Nikita Tovstolesonline
    <base href="x-msg://11/">

    Thanks for the tip, Stuart. I think I understand what’s happening but do have a “am I ”:

     

    1)      I see that artifact maven-metadata.xml, generated by deploy goal  (Mvn 3.0.4 and maven-deploy-plugin  2.7) does NOT contain <latest/> property at all – and understand that the file is unaltered when uploaded to nexus repo. (I verified by running deploy goal against local file system snapshotRepository in distributionManagement)

    2)      Running “rebuild metadata” task in Nexus OSS 2.0.0 generates maven-metadata.xml with <latest/> property set

    3)      Subsequent ‘maven deploy’ uploads do NOT alter <latest/> field (perhaps because mvn does not expect it to be present – since it’s not generated in #1)

     

    From the above, a catch-22 situation: if one ever runs ‘rebuild metadata’ task in Nexus, <latest/> property is introduced (by Nexus) - but is never subsequently updated by ‘mvn deploy’. So, it seems, either one must:
    1) never run ‘rebuild metadata’ (to never set <latest/> property) OR

    2) one must always trigger that task every time a different version of SNAPSHOT artifact is uploaded via ‘mvn deploy’ (to keep <latest/> property updated)

     

    I suppose I can achieve #2 via post-deploy call to nexus API, but is the above really by design? If not, which party (maven-deploy-plugin or Nexus ‘rebuild metadata’) should be behaving differently? Or am I missing something else?

     

    Thank you,

    -nikita

     

    From: Stuart McCulloch [mailto:[hidden email]
    Sent: Thursday, March 22, 2012 7:44 AM
    To: [hidden email]
    Subject: Re: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    On 22 Mar 2012, at 11:48, Nikita Tovstoles wrote:



    Update: I observed the following:

    ·         Running ‘rebuild metadata’ on repository from nexus UI fixes the problem – specifically API responds to v=LATEST with newest version (11-SNAPSHOT in the case below)

    ·         The only change to maven-metadata.xml from the above is: <latest/> updated from 10-SNAPSHOT to 11-SNAPSHOT. So ‘latest’ does matter for non-plugin artifacts – contrary to the FAQ (http://bit.ly/GEurFo )?

    ·         The cycle repeats, however – after newer 12-SNAPSHOT is published, maven-metadata.xml still lists 11-SNAPSHOT as <latest/> (albeit listing lastUpdated matching 12-SNAPSHOT) and Nexus API responds with 11-SNAPSHOT when asked for ‘v=LATEST’

     

    So, seems like one of the following must be true:

    1)      Mvn deploy uploads incorrect maven-metadata.xml (and <latest/> does matter)

    a.       I ran mvn deploy against a local file repo, and the resulting maven-metadata.xml did not have <latest/> property at all (using mvn 3.0.4 and maven-deploy-plugin 2.7)

    2)      Nexus does something to maven-metadata.xml on upload and the resulting file has wrong <latest/>

    3)      <latest/> is indeed irrelevant and Nexus REST API returns wrong version for some other reason (can Nexus API be caching a response?)

     

    Nexus only modifies the Maven metadata for a given repository when you explicitly ask to rebuild it, otherwise it is left to Maven to update.

    However, Maven no longer updates the LATEST tag on deploy, see http://jira.codehaus.org/browse/MDEPLOY-103 and its linked issues.



     

     

    From: Nikita Tovstoles [hidden email] 
    Sent: Tuesday, March 20, 2012 5:25 PM
    To: [hidden email]
    Subject: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Novice nexus oss (2.0.0) user here – getting unexpected results when requesting v=LATEST artifact from our hosted repo. I am hoping someone could explain what is wrong with our maven-metadata.xml (or my expectations of what v=LATEST returns). We have an non-plugin JAR artifact “castanealabs-config” in Snapshots repo (published via maven-deploy-plugin, fwiw). The two most recent versions are 10-SNAPSHOT and 11-SNAPSHOT. The latter was published most recently (and has the highest version by maven convention, as I understand it). Yet Nexus REST API (/artifact/maven/{resolve,redirect}) keeps returning most recent snapshot of 10-SNAPSHOT instead when asked for v=LATEST.

    Why?

    What inputs (from maven-metadata.xml at /group/artifact/maven-metadata.xml) does API evaluate to arrive at 10-SNAPSHOT. API responses below; attached are  maven-metadata.xml  files for:

    1)      10-SNAPSHOT

    2)      11-SNAPSHOT

    3)      artifact

    Notice that in artifact’s maven-metadata.xml lastUpdated matches the timestamp of 11-SNAPSHOT. From reading Nexus FAQ, my understanding is that versioning/latest attribute in that file is irrelevant since this is a non-plugin artifact.

    Thank you,

    -nikita

    Asking /resolve for ‘v=LATEST’:

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:08:19 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:08:19 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>10-20120320.074835-5</version>

        <baseVersion>10-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>5</snapshotBuildNumber>

        <snapshotTimeStamp>1332229715000</snapshotTimeStamp>

        <sha1>f107b5dd710dc3dbac8029ecb3f394b265e7c078</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/10-SNAPSHOT/castanealabs-config-10-20120320.074835-5.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Now ask for 11-SNAPSHOT explicitly – notice more recent <version/>:

    HTTP/1.1 200 OK

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:12:48 GMT

    Content-Type: application/xml; charset=UTF-8

    Date: Tue, 20 Mar 2012 22:12:48 GMT

    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept

    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4

    Content-Length: 638

    <artifact-resolution>

      <data>

        <presentLocally>true</presentLocally>

        <groupId>com.castanealabs</groupId>

        <artifactId>castanealabs-config</artifactId>

        <version>11-20120320.181629-2</version>

        <baseVersion>11-SNAPSHOT</baseVersion>

        <extension>jar</extension>

        <snapshot>true</snapshot>

        <snapshotBuildNumber>2</snapshotBuildNumber>

        <snapshotTimeStamp>1332267389000</snapshotTimeStamp>

        <sha1>d90c05740d587ae57fddd2318fc40258104283e2</sha1>

        <repositoryPath>/com/castanealabs/castanealabs-config/11-SNAPSHOT/castanealabs-config-11-20120320.181629-2.jar</repositoryPath>

      </data>

    </artifact-resolution>

    Maven-metadata.xml at /group/artifact/ level:

    <?xml version="1.0" encoding="UTF-8"?>

    <metadata>

    <groupId>com.castanealabs</groupId>

    <artifactId>castanealabs-config</artifactId>

    <versioning>

    <latest>10-SNAPSHOT</latest>

    <release></release>

    <versions>

    <version>1.0-SNAPSHOT</version>

    <version>7-SNAPSHOT</version>

    <version>8-SNAPSHOT</version>

    <version>10-SNAPSHOT</version>

    <version>11-SNAPSHOT</version>

    </versions>

    <lastUpdated>20120320181629</lastUpdated>

    </versioning>

    </metadata>

    Reply | Threaded |   
    Selected post

    Re: nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST

    Rich Seddononline
    <base href="x-msg://11/">With regards to your rebuilding metadata...  you really shouldn't run this unless you have a good reason to.   Maven is responsible for maintaining the metadata files, rebuilding them should be thought of as a "repair" operation.  

    Regarding Nexus setting "latest" after metadata rebuild, are these timestamped snapshots, or non-timestamped snapshots?  

    Rich



    On Mar 22, 2012, at 5:52 PM, Nikita Tovstoles wrote:

    Thanks for the tip, Stuart. I think I understand what’s happening but do have a “am I ”:
     
    1)      I see that artifact maven-metadata.xml, generated by deploy goal  (Mvn 3.0.4 and maven-deploy-plugin  2.7) does NOT contain <latest/> property at all – and understand that the file is unaltered when uploaded to nexus repo. (I verified by running deploy goal against local file system snapshotRepository in distributionManagement)
    2)      Running “rebuild metadata” task in Nexus OSS 2.0.0 generates maven-metadata.xml with <latest/> property set
    3)      Subsequent ‘maven deploy’ uploads do NOT alter <latest/> field (perhaps because mvn does not expect it to be present – since it’s not generated in #1)
     
    From the above, a catch-22 situation: if one ever runs ‘rebuild metadata’ task in Nexus, <latest/> property is introduced (by Nexus) - but is never subsequently updated by ‘mvn deploy’. So, it seems, either one must:
    1) never run ‘rebuild metadata’ (to never set <latest/> property) OR
    2) one must always trigger that task every time a different version of SNAPSHOT artifact is uploaded via ‘mvn deploy’ (to keep <latest/> property updated)
     
    I suppose I can achieve #2 via post-deploy call to nexus API, but is the above really by design? If not, which party (maven-deploy-plugin or Nexus ‘rebuild metadata’) should be behaving differently? Or am I missing something else?
     
    Thank you,
    -nikita
     
    From: Stuart McCulloch [mailto:[hidden email]
    Sent: Thursday, March 22, 2012 7:44 AM
    To: [hidden email]
    Subject: Re: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST
     
    On 22 Mar 2012, at 11:48, Nikita Tovstoles wrote:


    Update: I observed the following:
    ·         Running ‘rebuild metadata’ on repository from nexus UI fixes the problem – specifically API responds to v=LATEST with newest version (11-SNAPSHOT in the case below)
    ·         The only change to maven-metadata.xml from the above is: <latest/> updated from 10-SNAPSHOT to 11-SNAPSHOT. So ‘latest’ does matter for non-plugin artifacts – contrary to the FAQ (http://bit.ly/GEurFo )?
    ·         The cycle repeats, however – after newer 12-SNAPSHOT is published, maven-metadata.xml still lists 11-SNAPSHOT as <latest/> (albeit listing lastUpdated matching 12-SNAPSHOT) and Nexus API responds with 11-SNAPSHOT when asked for ‘v=LATEST’
     
    So, seems like one of the following must be true:
    1)      Mvn deploy uploads incorrect maven-metadata.xml (and <latest/> does matter)
    a.       I ran mvn deploy against a local file repo, and the resulting maven-metadata.xml did not have <latest/> property at all (using mvn 3.0.4 and maven-deploy-plugin 2.7)
    2)      Nexus does something to maven-metadata.xml on upload and the resulting file has wrong <latest/>
    3)      <latest/> is indeed irrelevant and Nexus REST API returns wrong version for some other reason (can Nexus API be caching a response?)
     
     
    Nexus only modifies the Maven metadata for a given repository when you explicitly ask to rebuild it, otherwise it is left to Maven to update.
     
    However, Maven no longer updates the LATEST tag on deploy, see http://jira.codehaus.org/browse/MDEPLOY-103 and its linked issues.


     
     
    From: Nikita Tovstoles [hidden email] 
    Sent: Tuesday, March 20, 2012 5:25 PM
    To: [hidden email]
    Subject: [nexus-user] nexus REST API /artifact/maven/[resolve|redirect] returns unexpected for v=LATEST
     
    Novice nexus oss (2.0.0) user here – getting unexpected results when requesting v=LATEST artifact from our hosted repo. I am hoping someone could explain what is wrong with our maven-metadata.xml (or my expectations of what v=LATEST returns). We have an non-plugin JAR artifact “castanealabs-config” in Snapshots repo (published via maven-deploy-plugin, fwiw). The two most recent versions are 10-SNAPSHOT and 11-SNAPSHOT. The latter was published most recently (and has the highest version by maven convention, as I understand it). Yet Nexus REST API (/artifact/maven/{resolve,redirect}) keeps returning most recent snapshot of 10-SNAPSHOT instead when asked for v=LATEST.
     
    Why?
    What inputs (from maven-metadata.xml at /group/artifact/maven-metadata.xml) does API evaluate to arrive at 10-SNAPSHOT. API responses below; attached are  maven-metadata.xml  files for:
    1)      10-SNAPSHOT
    2)      11-SNAPSHOT
    3)      artifact
     
    Notice that in artifact’s maven-metadata.xml lastUpdated matches the timestamp of 11-SNAPSHOT. From reading Nexus FAQ, my understanding is that versioning/latest attribute in that file is irrelevant since this is a non-plugin artifact.
     
    Thank you,
    -nikita
     
    Asking /resolve for ‘v=LATEST’:
     
    HTTP/1.1 200 OK
    Date: Tue, 20 Mar 2012 22:08:19 GMT
    Set-Cookie: rememberMe=deleteMe; Path=/nexus; Max-Age=0; Expires=Mon, 19-Mar-2012 22:08:19 GMT
    Content-Type: application/xml; charset=UTF-8
    Date: Tue, 20 Mar 2012 22:08:19 GMT
    Vary: Accept-Charset, Accept-Encoding, Accept-Language, Accept
    Server: Noelios-Restlet-Engine/1.1.6-SONATYPE-5348-V4
    Content-Length: 638
     
    <artifact-resolution>
      <data>
        <presentLocally>true</presentLocally>
        <groupId>com.castanealabs</groupId>
        <artifactId>castanealabs-config</artifactId>
        <version>10-20120320.074835-5</version>
        <baseVersion>10-SNAPSHOT</baseVersion>
        <extension>jar</extension>
        <snapshot>true</snapshot>
        <snapshotBuildNumber>5</snapshotBuildNumber>
        <snapshotTimeStamp>1332229715000</snapshotTimeStamp>
        <sha1>f107b5dd710dc3dbac8029ecb3f394b265e7c078</sha1>
        <repositoryPath>/com/castanealabs/castanealabs-config/10-SNAPSHOT/castanealabs-config-10-20120320.074835-5.jar</repositoryPath>
      </data>
    </artifact-resolution>
     
    Now ask for 11-SNAPSHOT explicitly – notice more
  • 相关阅读:
    hive实战记录
    并发
    软件安装
    idea
    maven
    thingkinginjava
    JVM
    并发模块concurrent
    ffmpeg_分割一个mp4文件到多个小的mp4文件
    用 ffmpeg 压缩视频
  • 原文地址:https://www.cnblogs.com/duyinqiang/p/5696346.html
Copyright © 2020-2023  润新知