looks like it is bug from maven itself since the merge code is from there On Fri, Mar 15, 2013 at 11:10 AM, Jim McCaskey <[email protected]> wrote: > Actually, I don't think the merge is doing the right thing, at least not for > SNAPSHOT's. If you look at the example maven-metadata.xml file below, it > fills in the <versioning> section properly. But the part where it actually > lists the snapshot versions under <snapshotVersions> is not getting updated. > > I'm making use of my repository managers Rebuild Metadata function to get the > maven-metadata.xml files updated properly. > > IMHO, someone who knows more about those maven-metadata.xml files would need > to tell you what is the "right" thing to have in there. As far as I know that > file under the version directory should just list the latest SNAPSHOT version > to use. > > -Jim > > -----Original Message----- > From: Dan Tran [mailto:[email protected]] > Sent: Friday, March 15, 2013 10:43 AM > To: Maven Users List > Subject: Re: merge-maven-repos problems with maven-metadata.xml > > So far what I hear is the merge is doing the right thing, however, we > still need to reindexing repo manager to pickup metadata changes. > > if not so, we need more details about how exactly metadata must be > after the merge without the need to run the reindex > > -D > > On Fri, Mar 15, 2013 at 6:50 AM, Jim McCaskey > <[email protected]> wrote: >> Hi there, >> >> Your probably right Dan. I did take a quick walk through the code and it >> looked like the wagon-maven-plugin just calls a .merge on the >> maven-metadata.xml files from some other package. I felt there be dragons, >> so came up with another "solution". >> >> Thanks to Alejandro for the idea of just triggering something on the server. >> I wanted to be a bit more tactical though. I was able to rebuild just the >> Metadata (which is all my builds need to keep going during the day) by doing >> this: >> >> curl --user <uid>:<pwd> -X DELETE --insecure >> https://repoUrl/nexus/service/local/metadata/repositories/repoName/content/path/to/artifact >> >> That takes seconds to accomplish instead of a few minutes as that was >> tripping up my Jenkins server. It does put and extra burden on me to >> correctly identify which artifacts need to be rebuilt, but I figure a little >> scripting can accomplish that. We rebuild the indexes every night, which is >> "good enough" for what we need. I basically followed the REST documentation >> on my server. I found the docs here as well: >> >> http://nexus.xwiki.org/nexus/nexus-core-documentation-plugin/core/docs/rest.metadata.domain.target.content.html >> >> I'm back in business for now. Thanks everyone! >> >> -Jim >> >> -----Original Message----- >> From: Dan Tran [mailto:[email protected]] >> Sent: Thursday, March 14, 2013 6:36 PM >> To: Maven Users List >> Subject: Re: merge-maven-repos problems with maven-metadata.xml >> >> You may want to talk a look at metadata merge logic under >> wagon-maven-plugin and fix it, i think it is doable >> >> -D >> >> On Thu, Mar 14, 2013 at 12:16 PM, <[email protected]> wrote: >> >>> 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 >>> >>> [image: Inactive hide details for Jim McCaskey ---2013-03-14 >>> 14:38:57---It's not a Maven build. It's an old legacy non-java (mostly) >>> b]Jim >>> McCaskey ---2013-03-14 14:38:57---It's not a Maven build. It's an old >>> legacy non-java (mostly) build that takes 1.5 hours to build, b >>> >>> 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] <[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] <[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. >>> >>> >> 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
