i do something similar to fix a bug in nexus (https://issues.sonatype.org/browse/NEXUS-5525)
since it is a jenkins build, i just trigger a scheduled (manual) task to reindex the repo on build finish. The command i use to trigger it is /usr/bin/wget --user=something --password=my-pass http://url/to/repo/nexus/service/local/schedule_run/21 where 21 is the id of the reindex job So in summary: -create scheduled job to "repair repositories index" -somehow (jenkins in my case) trigger a command to invoke the REST service -enjoy I did not find a REST service directly to trigger a reindex, thus the hack with the scheduled job. Let me know if you find something better hope it helps, Alejandro From: Jim McCaskey <[email protected]> To: Maven Users List <[email protected]>, Date: 2013-03-14 14:38 Subject: RE: merge-maven-repos problems with maven-metadata.xml It's not a Maven build. It's an old legacy non-java (mostly) build that takes 1.5 hours to build, but we still want to crank that whole thing when there is a change. I don't publish the build till it is all done. I use a stub pom.xml to generate the staging-repo with a bunch of deploy executions (which I will never show anyone in the Maven community for fear of being forever banned). Once that whole things works, then I merge that build into our SNAPSHOT repo. Works great except for the maven-metadata.xml files. I think this is the point where folks start telling me I'm doing it wrong. :) Honestly, we do our pure Maven stuff "right", it's just this clunker that we have to hack around a little. Our non-SNAPSHOT builds work fine, I just did not know SNAPSHOT's where treated different, so now I'll have to come up with a workaround to get the maven-metadata.xml files rigged properly. You can do that through the Nexus UI by clicking on the "Rebuild Metadata" button. Given that the Nexus folks make a big deal about everything being available through REST, there's got to be some way to do that programmatically. Anyone got a hint? (I know, go ask on the Nexus list) -Jim -----Original Message----- From: Dan Tran [mailto:[email protected]] Sent: Thursday, March 14, 2013 11:10 AM To: Maven Users List Subject: Re: merge-maven-repos problems with maven-metadata.xml You need to reindex for both cases any way since the repository is not aware of your changes. Without reindexing, it may not serve your new artifact. Just curious, why do you want to merge snaphot repo, why not just push the artifact directly to your snapshot repos? -D On Thu, Mar 14, 2013 at 6:57 AM, Jim McCaskey <[email protected]> wrote: > Ouch... Is that documented somewhere? I checked the bug tracker and uncle Google and couldn't find anything regarding that. I went ahead and opened an issue in Jira: > > http://jira.codehaus.org/browse/MOJO-1913 > > I wonder what would be quicker. Finding a hack around or fixing the module. :) It would probably be easy to fire off a Nexus reindex of the effected artifacts which would "fix" the problem for me. > > -Jim > > -----Original Message----- > From: Dan Tran [mailto:[email protected]] > Sent: Thursday, March 14, 2013 4:06 AM > To: Maven Users List > Subject: Re: merge-maven-repos problems with maven-metadata.xml > > merge-maven-repos mojo works with release repos ONLY. Merging > snapshot repos requires enhancement > > -Dan > > On Wed, Mar 13, 2013 at 11:29 AM, Jim McCaskey > <[email protected]> wrote: >> Hello all, >> >> Below you will find a maven-metadata.xml file from my Nexus repository (GAV changed to protect the innocent). What you will notice is that the <snapshot> timestamp and the <snapshotVersions> do not match. I don't think that it's a Nexus repo issue. Perhaps a bug in merge-maven-repos. >> >> I build the components to an empty directory using the altDeploymentRepository property: >> >> -DaltDeploymentRepository=repo::default::file://E:\builddir\staging-repo deploy >> >> I then publish this component to Nexus using this (using Maven 3.0.4): >> >> org.codehaus.mojo:wagon-maven-plugin:1.0-beta-4:merge-maven-repos >> >> This seems to work just fine for my non-SNAPSHOT builds. But the CI builds seem to get their maven-metadata.xml file messed up every time those SNAPSHOT builds run. This took a while to track down because I run "Update Repositories Index" every night and Nexus fixes the maven-metadata.xml. And this is a very long build. >> >> FWIW, this is a shim between legacy code and our newer, all Maven build code. As you can tell we just zip that mess up and use it whole sale in downstream builds. >> >> Any thoughts on how I can fix this? Perhaps it's just a bug in wagon:merge-maven-repos? >> >> -Jim >> >> >> <?xml version="1.0" encoding="UTF-8"?> >> <metadata modelVersion="1.1.0"> >> <groupId>myGroup</groupId> >> <artifactId>MyArtifact</artifactId> >> <version>10.2.6-SNAPSHOT</version> >> <versioning> >> <snapshot> >> <timestamp>20130313.165705</timestamp> >> <buildNumber>1</buildNumber> >> </snapshot> >> <lastUpdated>20130313165705</lastUpdated> >> <snapshotVersions> >> <snapshotVersion> >> <classifier>MyClassifier</classifier> >> <extension>zip</extension> >> <value>10.2.6-20130311.175410-1</value> >> <updated>20130311175410</updated> >> </snapshotVersion> >> <snapshotVersion> >> <extension>pom</extension> >> <value>10.2.6-20130311.175410-1</value> >> <updated>20130311175410</updated> >> </snapshotVersion> >> </snapshotVersions> >> </versioning> >> </metadata> >> >> NOTICE: All information in and attached to this email may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > NOTICE: All information in and attached to this email may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] NOTICE: All information in and attached to this email may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
