You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Jim McCaskey <ji...@pervasive.com> on 2013/03/13 19:29:18 UTC

merge-maven-repos problems with maven-metadata.xml

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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: merge-maven-repos problems with maven-metadata.xml

Posted by Dan Tran <da...@gmail.com>.
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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
> <ji...@pervasive.com> 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:dantran@gmail.com]
>> 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, <Al...@miranda.com> 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 <ji...@pervasive.com>
>>> To: Maven Users List <us...@maven.apache.org>,
>>> 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:dantran@gmail.com <da...@gmail.com>]
>>> 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
>>> <ji...@pervasive.com> 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:dantran@gmail.com <da...@gmail.com>]
>>> > 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
>>> > <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>>> >> For additional commands, e-mail: users-help@maven.apache.org
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: users-help@maven.apache.org
>>> >
>>> >
>>> > 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: merge-maven-repos problems with maven-metadata.xml

Posted by Jim McCaskey <ji...@pervasive.com>.
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:dantran@gmail.com]
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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, <Al...@miranda.com> 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 <ji...@pervasive.com>
>> To: Maven Users List <us...@maven.apache.org>,
>> 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:dantran@gmail.com <da...@gmail.com>]
>> 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
>> <ji...@pervasive.com> 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:dantran@gmail.com <da...@gmail.com>]
>> > 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
>> > <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>> > 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: merge-maven-repos problems with maven-metadata.xml

Posted by Dan Tran <da...@gmail.com>.
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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, <Al...@miranda.com> 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 <ji...@pervasive.com>
>> To: Maven Users List <us...@maven.apache.org>,
>> 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:dantran@gmail.com <da...@gmail.com>]
>> 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
>> <ji...@pervasive.com> 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:dantran@gmail.com <da...@gmail.com>]
>> > 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
>> > <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>> > 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: merge-maven-repos problems with maven-metadata.xml

Posted by Jim McCaskey <ji...@pervasive.com>.
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:dantran@gmail.com]
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, <Al...@miranda.com> 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 <ji...@pervasive.com>
> To: Maven Users List <us...@maven.apache.org>,
> 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:dantran@gmail.com <da...@gmail.com>]
> 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
> <ji...@pervasive.com> 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:dantran@gmail.com <da...@gmail.com>]
> > 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
> > <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: merge-maven-repos problems with maven-metadata.xml

Posted by Dan Tran <da...@gmail.com>.
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, <Al...@miranda.com> 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 <ji...@pervasive.com>
> To: Maven Users List <us...@maven.apache.org>,
> 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:dantran@gmail.com <da...@gmail.com>]
> 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
> <ji...@pervasive.com> 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:dantran@gmail.com <da...@gmail.com>]
> > 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
> > <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
> > 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
> 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.
>
>

RE: merge-maven-repos problems with maven-metadata.xml

Posted by Al...@miranda.com.
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 <ji...@pervasive.com>
To:	Maven Users List <us...@maven.apache.org>,
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:dantran@gmail.com]
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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
> <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

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.

RE: merge-maven-repos problems with maven-metadata.xml

Posted by Jim McCaskey <ji...@pervasive.com>.
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:dantran@gmail.com]
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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
> <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: merge-maven-repos problems with maven-metadata.xml

Posted by Dan Tran <da...@gmail.com>.
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
<ji...@pervasive.com> 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:dantran@gmail.com]
> 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
> <ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

RE: merge-maven-repos problems with maven-metadata.xml

Posted by Jim McCaskey <ji...@pervasive.com>.
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:dantran@gmail.com]
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
<ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


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.

Re: merge-maven-repos problems with maven-metadata.xml

Posted by Dan Tran <da...@gmail.com>.
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
<ji...@pervasive.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org