Re: Is there any way to stop the same version of pom file/build being built more than once?
Ic. so instead of upgrade from same machine, you have a new server then migrate the files and directories over... Thank you for your reply. B. On Thu, Jan 6, 2011 at 10:31 AM, Nick Stolwijk wrote: > We just did a reinstall on a new server and planning to copy the > repositories by hand and do a reindex. We had a testrun and it went > painlessly. The mirror and snapshot repositories we just deleted, as > to do some cleanup. > > Hth, > > Nick Stolwijk > ~Senior Java Developer~ > > iPROFS > Wagenweg 208 > 2012 NM Haarlem > T +31 23 547 6369 > F +31 23 547 6370 > I www.iprofs.nl > > > > On Thu, Jan 6, 2011 at 7:24 PM, baz themail wrote: >> How is the upgrade process from 1.3.6 to 1.8.0.1? Painless? >> >> On Thu, Jan 6, 2011 at 10:12 AM, Nick Stolwijk >> wrote: >>> I've also checked 1.3.6 (still in production here, Saturday we are >>> moving to 1.8.0.1) and, indeed, it isn't there. You have to upgrade to >>> a newer version to have it. It isn't a Pro feature, the free version >>> also has it. >>> >>> With regards, >>> >>> Nick Stolwijk >>> ~Senior Java Developer~ >>> >>> iPROFS >>> Wagenweg 208 >>> 2012 NM Haarlem >>> T +31 23 547 6369 >>> F +31 23 547 6370 >>> I www.iprofs.nl >>> >>> >>> >>> On Thu, Jan 6, 2011 at 7:08 PM, baz themail wrote: >>>> Nick, >>>> >>>> I am using Nexus open source version 1.3.6. >>>> >>>> - Open repository named "releases". >>>> - Configuration tab. >>>> - I see "Repositoy ID", "Repository Name", "Repository type", >>>> "Provider", "Format", "Repository Policy", "Default Local Storage >>>> Location", "Override Local Storage Location"; Access settings: "Allow >>>> Deployment", "Allow File Browsing", "Include in Search"; Expiration >>>> settings: "Not found cache TTL". >>>> >>>> I do not see Deployment policy. Is this a feature for PRO? >>>> >>>> Thanks. >>>> >>>> B. >>>> >>>> On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk >>>> wrote: >>>>> I just checked our 1.8.0.1 instance of Nexus and it is right there >>>>> under the configuration of a hosted repository: >>>>> >>>>> Deployment policy: >>>>> Allow redeploy >>>>> Disallow redeploy >>>>> Read only >>>>> >>>>> Hth, >>>>> >>>>> Nick Stolwijk >>>>> ~Senior Java Developer~ >>>>> >>>>> iPROFS >>>>> Wagenweg 208 >>>>> 2012 NM Haarlem >>>>> T +31 23 547 6369 >>>>> F +31 23 547 6370 >>>>> I www.iprofs.nl >>>>> >>>>> >>>>> >>>>> On Thu, Jan 6, 2011 at 6:58 PM, baz themail wrote: >>>>>> Todd, thats one of the function that I thought Nexus has... but I >>>>>> cannot find the usage for it. Is it only available in Pro version? >>>>>> >>>>>> On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) >>>>>> wrote: >>>>>>> Configure your Nexus server to not allow artifacts to get overwritten. >>>>>>> You can't stop the build from happening, but you can stop the artifact >>>>>>> from being deployed. >>>>>>> >>>>>>>> -Original Message- >>>>>>>> From: baz themail [mailto:bazthem...@gmail.com] >>>>>>>> Sent: Wednesday, January 05, 2011 12:55 PM >>>>>>>> To: Maven Users List >>>>>>>> Subject: Re: Is there any way to stop the same version of pom >>>>>>>> file/build >>>>>>>> being built more than once? >>>>>>>> >>>>>>>> Wendy, thanks for your reply. >>>>>>>> >>>>>>>> Here is the example: >>>>>>>> >>>>>>>> 1. Someone need to fix a bug in production. >>>>>>>> 2. Create a new branch for bug fix based on a label. >>>>>>>> 3. The newly created branch will contain older pom files with older >>>>>>>> vers
Re: Is there any way to stop the same version of pom file/build being built more than once?
How is the upgrade process from 1.3.6 to 1.8.0.1? Painless? On Thu, Jan 6, 2011 at 10:12 AM, Nick Stolwijk wrote: > I've also checked 1.3.6 (still in production here, Saturday we are > moving to 1.8.0.1) and, indeed, it isn't there. You have to upgrade to > a newer version to have it. It isn't a Pro feature, the free version > also has it. > > With regards, > > Nick Stolwijk > ~Senior Java Developer~ > > iPROFS > Wagenweg 208 > 2012 NM Haarlem > T +31 23 547 6369 > F +31 23 547 6370 > I www.iprofs.nl > > > > On Thu, Jan 6, 2011 at 7:08 PM, baz themail wrote: >> Nick, >> >> I am using Nexus open source version 1.3.6. >> >> - Open repository named "releases". >> - Configuration tab. >> - I see "Repositoy ID", "Repository Name", "Repository type", >> "Provider", "Format", "Repository Policy", "Default Local Storage >> Location", "Override Local Storage Location"; Access settings: "Allow >> Deployment", "Allow File Browsing", "Include in Search"; Expiration >> settings: "Not found cache TTL". >> >> I do not see Deployment policy. Is this a feature for PRO? >> >> Thanks. >> >> B. >> >> On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk >> wrote: >>> I just checked our 1.8.0.1 instance of Nexus and it is right there >>> under the configuration of a hosted repository: >>> >>> Deployment policy: >>> Allow redeploy >>> Disallow redeploy >>> Read only >>> >>> Hth, >>> >>> Nick Stolwijk >>> ~Senior Java Developer~ >>> >>> iPROFS >>> Wagenweg 208 >>> 2012 NM Haarlem >>> T +31 23 547 6369 >>> F +31 23 547 6370 >>> I www.iprofs.nl >>> >>> >>> >>> On Thu, Jan 6, 2011 at 6:58 PM, baz themail wrote: >>>> Todd, thats one of the function that I thought Nexus has... but I >>>> cannot find the usage for it. Is it only available in Pro version? >>>> >>>> On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) >>>> wrote: >>>>> Configure your Nexus server to not allow artifacts to get overwritten. >>>>> You can't stop the build from happening, but you can stop the artifact >>>>> from being deployed. >>>>> >>>>>> -Original Message- >>>>>> From: baz themail [mailto:bazthem...@gmail.com] >>>>>> Sent: Wednesday, January 05, 2011 12:55 PM >>>>>> To: Maven Users List >>>>>> Subject: Re: Is there any way to stop the same version of pom file/build >>>>>> being built more than once? >>>>>> >>>>>> Wendy, thanks for your reply. >>>>>> >>>>>> Here is the example: >>>>>> >>>>>> 1. Someone need to fix a bug in production. >>>>>> 2. Create a new branch for bug fix based on a label. >>>>>> 3. The newly created branch will contain older pom files with older >>>>>> version that already released in Nexus (or any Maven based >>>>>> repository). >>>>>> 4. Logically, once the branch is created from an older label, in order >>>>>> to avoid redeploying the old version numbers, the version number >>>>>> should be changed. >>>>>> 5. Say, if #4 is skipped, then the same version number that exist in >>>>>> Nexus will be overwritten after performing a release build. >>>>>> 6. This is to assume that we should keep the old release version even >>>>>> if it is buggy. >>>>>> >>>>>> So, my question is: Is there any way to skip #4 by having some Maven >>>>>> type mechanism to check and stop a release build if the version >>>>>> already exist in maven repo? >>>>>> >>>>>> Thanks. >>>>>> >>>>>> B. >>>>>> >>>>>> On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wrote: >>>>>> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail >>>>>> wrote: >>>>>> >> Hi, >>>>>> >> Is there any way to stop the same version of pom file/build being >>>>>> >> built more than once? >>>>>> > >>>>>> > Being _bu
Re: Is there any way to stop the same version of pom file/build being built more than once?
Nick, I am using Nexus open source version 1.3.6. - Open repository named "releases". - Configuration tab. - I see "Repositoy ID", "Repository Name", "Repository type", "Provider", "Format", "Repository Policy", "Default Local Storage Location", "Override Local Storage Location"; Access settings: "Allow Deployment", "Allow File Browsing", "Include in Search"; Expiration settings: "Not found cache TTL". I do not see Deployment policy. Is this a feature for PRO? Thanks. B. On Thu, Jan 6, 2011 at 10:02 AM, Nick Stolwijk wrote: > I just checked our 1.8.0.1 instance of Nexus and it is right there > under the configuration of a hosted repository: > > Deployment policy: > Allow redeploy > Disallow redeploy > Read only > > Hth, > > Nick Stolwijk > ~Senior Java Developer~ > > iPROFS > Wagenweg 208 > 2012 NM Haarlem > T +31 23 547 6369 > F +31 23 547 6370 > I www.iprofs.nl > > > > On Thu, Jan 6, 2011 at 6:58 PM, baz themail wrote: >> Todd, thats one of the function that I thought Nexus has... but I >> cannot find the usage for it. Is it only available in Pro version? >> >> On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) >> wrote: >>> Configure your Nexus server to not allow artifacts to get overwritten. You >>> can't stop the build from happening, but you can stop the artifact from >>> being deployed. >>> >>>> -Original Message- >>>> From: baz themail [mailto:bazthem...@gmail.com] >>>> Sent: Wednesday, January 05, 2011 12:55 PM >>>> To: Maven Users List >>>> Subject: Re: Is there any way to stop the same version of pom file/build >>>> being built more than once? >>>> >>>> Wendy, thanks for your reply. >>>> >>>> Here is the example: >>>> >>>> 1. Someone need to fix a bug in production. >>>> 2. Create a new branch for bug fix based on a label. >>>> 3. The newly created branch will contain older pom files with older >>>> version that already released in Nexus (or any Maven based >>>> repository). >>>> 4. Logically, once the branch is created from an older label, in order >>>> to avoid redeploying the old version numbers, the version number >>>> should be changed. >>>> 5. Say, if #4 is skipped, then the same version number that exist in >>>> Nexus will be overwritten after performing a release build. >>>> 6. This is to assume that we should keep the old release version even >>>> if it is buggy. >>>> >>>> So, my question is: Is there any way to skip #4 by having some Maven >>>> type mechanism to check and stop a release build if the version >>>> already exist in maven repo? >>>> >>>> Thanks. >>>> >>>> B. >>>> >>>> On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wrote: >>>> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail >>>> wrote: >>>> >> Hi, >>>> >> Is there any way to stop the same version of pom file/build being >>>> >> built more than once? >>>> > >>>> > Being _built_? Probably not... anyone can check out a tag and >>>> > re-build that version locally, nothing to prevent that from happening. >>>> > (Nor should there be.) >>>> > >>>> > What's the real underlying problem? >>>> > >>>> > My guess is that it's about not overwriting released versions. In >>>> > which case... are you using -SNAPSHOT version numbers and going >>>> > through a release process? A repository manager to store your >>>> > artifacts? >>>> > >>>> > Tell us more about your situation and most likely someone will have >>>> > some advice for you. >>>> > >>>> > -- >>>> > Wendy >>>> > >>>> > - >>>> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> > For additional commands, e-mail: users-h...@maven.apache.org >>>> > >>>> > >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
Todd, thats one of the function that I thought Nexus has... but I cannot find the usage for it. Is it only available in Pro version? On Wed, Jan 5, 2011 at 9:58 AM, Thiessen, Todd (Todd) wrote: > Configure your Nexus server to not allow artifacts to get overwritten. You > can't stop the build from happening, but you can stop the artifact from being > deployed. > >> -Original Message----- >> From: baz themail [mailto:bazthem...@gmail.com] >> Sent: Wednesday, January 05, 2011 12:55 PM >> To: Maven Users List >> Subject: Re: Is there any way to stop the same version of pom file/build >> being built more than once? >> >> Wendy, thanks for your reply. >> >> Here is the example: >> >> 1. Someone need to fix a bug in production. >> 2. Create a new branch for bug fix based on a label. >> 3. The newly created branch will contain older pom files with older >> version that already released in Nexus (or any Maven based >> repository). >> 4. Logically, once the branch is created from an older label, in order >> to avoid redeploying the old version numbers, the version number >> should be changed. >> 5. Say, if #4 is skipped, then the same version number that exist in >> Nexus will be overwritten after performing a release build. >> 6. This is to assume that we should keep the old release version even >> if it is buggy. >> >> So, my question is: Is there any way to skip #4 by having some Maven >> type mechanism to check and stop a release build if the version >> already exist in maven repo? >> >> Thanks. >> >> B. >> >> On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wrote: >> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail >> wrote: >> >> Hi, >> >> Is there any way to stop the same version of pom file/build being >> >> built more than once? >> > >> > Being _built_? Probably not... anyone can check out a tag and >> > re-build that version locally, nothing to prevent that from happening. >> > (Nor should there be.) >> > >> > What's the real underlying problem? >> > >> > My guess is that it's about not overwriting released versions. In >> > which case... are you using -SNAPSHOT version numbers and going >> > through a release process? A repository manager to store your >> > artifacts? >> > >> > Tell us more about your situation and most likely someone will have >> > some advice for you. >> > >> > -- >> > Wendy >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Is there any way to stop the same version of pom file/build being built more than once?
Wendy, thanks for your reply. Here is the example: 1. Someone need to fix a bug in production. 2. Create a new branch for bug fix based on a label. 3. The newly created branch will contain older pom files with older version that already released in Nexus (or any Maven based repository). 4. Logically, once the branch is created from an older label, in order to avoid redeploying the old version numbers, the version number should be changed. 5. Say, if #4 is skipped, then the same version number that exist in Nexus will be overwritten after performing a release build. 6. This is to assume that we should keep the old release version even if it is buggy. So, my question is: Is there any way to skip #4 by having some Maven type mechanism to check and stop a release build if the version already exist in maven repo? Thanks. B. On Tue, Jan 4, 2011 at 10:01 AM, Wendy Smoak wrote: > On Tue, Jan 4, 2011 at 12:28 PM, baz themail wrote: >> Hi, >> Is there any way to stop the same version of pom file/build being >> built more than once? > > Being _built_? Probably not... anyone can check out a tag and > re-build that version locally, nothing to prevent that from happening. > (Nor should there be.) > > What's the real underlying problem? > > My guess is that it's about not overwriting released versions. In > which case... are you using -SNAPSHOT version numbers and going > through a release process? A repository manager to store your > artifacts? > > Tell us more about your situation and most likely someone will have > some advice for you. > > -- > Wendy > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Is there any way to stop the same version of pom file/build being built more than once?
Hi, Is there any way to stop the same version of pom file/build being built more than once? Thanks. B. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to prune contents of the local repo?
Hi, 1. What is the best and recommended way to limit the size of the local maven repo? Currently, I am having a cron job to remove older SNAPSHOT. 2. Is there any way to keep certain release builds but not others? Meaning, is there any type of promotion mechanism in maven to mark some releases in local repo? 3. Is there any way to stop the same version of pom file/build being built more than once? Thanks. B. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
Yeah, unfortunately, the delete has been done in system/file level and not via Nexus. :( On Thu, Sep 23, 2010 at 4:11 PM, Brian Fox wrote: > Nexus has a trash folder that holds all files deleted. > (sonatype-work/nexus/trash) Hopefully they didn't also purge that and > you can just recover the files from there. > > Otherwise you could manually load the files from your local into > nexus' storage folder, the do a clear cache and reindex. > > Sent from my iPad > > On Sep 23, 2010, at 9:15 AM, baz themail wrote: > >> Ummm, thanks. I read that and i understand that deploy:deploy-file can >> deploy files to remote repo. I guess I am confused by reading the >> comments here in this thread. >> >> I think at one point, I replied and described using deploy-file and >> some replied that it is not suitable in my situation. >> >> Just repeating my situation: IT guys removed some files from Nexus' >> directories. Some pom files (including parent pom file) and artifacts >> are now missing. I am trying to recover some of the artifacts from >> build machine to remote repository. The Nexus is assumed without >> backup at this point. >> >> So, using deploy-file to deploy missing artifacts one by one is the >> best way to do it? >> >> Thanks. A. >> >> On Thu, Sep 23, 2010 at 8:51 AM, Justin Edelson >> wrote: >>> The fact that the artifacts are in your local repository is irrelevant. >>> Put that out of your mind. All that matters is that you have an artifact >>> and a pom and you want to deploy them to a remote repository. That's >>> what deploy-file does. >>> >>> All you have to do is: >>> >>> mvn deploy:deploy-file -Durl= -DrepositoryId= >>> -Dfile= -DpomFile= >>> >>> This is described on the page you linked to. If you have constructive >>> suggestions as to how to make this more obvious, feel free to submit >>> documentation JIRAs and I'm sure the plugin developers will take those >>> under advisement. >>> >>> On 9/23/10 11:42 AM, baz themail wrote: >>>> I am sorry if i cause the group to over-react about this real issue >>>> that i am here. >>>> >>>> I read the wiki page >>>> http://maven.apache.org/plugins/maven-deploy-plugin/usage.html three >>>> (or more) times now. I still not sure how to deploy older artifacts >>>> from local repository to remote repository without the need of >>>> recompiling older version of source code. >>>> >>>> It may be a simple thing to do. Am i missing something for the page? >>>> Or am i still not sure the usage? Or, the information is not from that >>>> page and need some people with the experience to answer? >>>> >>>> On Wed, Sep 22, 2010 at 11:07 PM, Anders Hammar wrote: >>>>> I second Wayne here. We'd be happy to help, but you have to do some job >>>>> yourself. >>>>> A pointer: look at the deploy-file goal of maven-deploy-plugin. >>>>> >>>>> /Anders >>>>> >>>>> On Thu, Sep 23, 2010 at 04:56, Wayne Fay wrote: >>>>> >>>>>>> If there are version 1.0.0.0, 2.0.0.0 and 3.0.0.0 of A in my local >>>>>>> repo. If I go to the location/workspace where I built A. If I type >>>>>>> "mvn deploy -Dversion=2.0.0.0, then will this deploy command deploy >>>>>>> the 2.0.0.0 from my local repository to remote repository without >>>>>>> re-building it? >>>>>> >>>>>> No, that will not work. >>>>>> >>>>>> Honestly, I give up until you go read the documentation and >>>>>> demonstrate that you've read it (and tried things yourself) before >>>>>> replying again. >>>>>> >>>>>> Wayne >>>>>> >>>>>> - >>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
anders, Yes, i am planning to back up the local repo first. Thanks guys... On Thu, Sep 23, 2010 at 10:43 AM, Anders Hammar wrote: > As you don't seem to be fully comfortable with Maven, I suggest that you > either use the staging feature of Nexus Pro or (if you're using Nexus OSS) > set up a temporary repo which you practice this on. Then, as long as you > don't delete the local files, you can't mess anything up. > > As a Nexus tip, when you eventually have the files in the right repo you > probably need to fix the metadata and re-index (in Nexus), as I understand > that someone has been messing around with the file system (when removing the > artifacts). > > /Anders > > On Thu, Sep 23, 2010 at 18:45, Wayne Fay wrote: > >> > I think at one point, I replied and described using deploy-file and >> > some replied that it is not suitable in my situation. >> >> You thought wrong. Go back and read the thread. No one ever said that. >> >> > So, using deploy-file to deploy missing artifacts one by one is the >> > best way to do it? >> >> Yes >> Ja >> Si >> Oui >> Da >> Hai >> Do you need it in another language? >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
Ummm, thanks. I read that and i understand that deploy:deploy-file can deploy files to remote repo. I guess I am confused by reading the comments here in this thread. I think at one point, I replied and described using deploy-file and some replied that it is not suitable in my situation. Just repeating my situation: IT guys removed some files from Nexus' directories. Some pom files (including parent pom file) and artifacts are now missing. I am trying to recover some of the artifacts from build machine to remote repository. The Nexus is assumed without backup at this point. So, using deploy-file to deploy missing artifacts one by one is the best way to do it? Thanks. A. On Thu, Sep 23, 2010 at 8:51 AM, Justin Edelson wrote: > The fact that the artifacts are in your local repository is irrelevant. > Put that out of your mind. All that matters is that you have an artifact > and a pom and you want to deploy them to a remote repository. That's > what deploy-file does. > > All you have to do is: > > mvn deploy:deploy-file -Durl= -DrepositoryId= > -Dfile= -DpomFile= > > This is described on the page you linked to. If you have constructive > suggestions as to how to make this more obvious, feel free to submit > documentation JIRAs and I'm sure the plugin developers will take those > under advisement. > > On 9/23/10 11:42 AM, baz themail wrote: >> I am sorry if i cause the group to over-react about this real issue >> that i am here. >> >> I read the wiki page >> http://maven.apache.org/plugins/maven-deploy-plugin/usage.html three >> (or more) times now. I still not sure how to deploy older artifacts >> from local repository to remote repository without the need of >> recompiling older version of source code. >> >> It may be a simple thing to do. Am i missing something for the page? >> Or am i still not sure the usage? Or, the information is not from that >> page and need some people with the experience to answer? >> >> On Wed, Sep 22, 2010 at 11:07 PM, Anders Hammar wrote: >>> I second Wayne here. We'd be happy to help, but you have to do some job >>> yourself. >>> A pointer: look at the deploy-file goal of maven-deploy-plugin. >>> >>> /Anders >>> >>> On Thu, Sep 23, 2010 at 04:56, Wayne Fay wrote: >>> >>>>> If there are version 1.0.0.0, 2.0.0.0 and 3.0.0.0 of A in my local >>>>> repo. If I go to the location/workspace where I built A. If I type >>>>> "mvn deploy -Dversion=2.0.0.0, then will this deploy command deploy >>>>> the 2.0.0.0 from my local repository to remote repository without >>>>> re-building it? >>>> >>>> No, that will not work. >>>> >>>> Honestly, I give up until you go read the documentation and >>>> demonstrate that you've read it (and tried things yourself) before >>>> replying again. >>>> >>>> Wayne >>>> >>>> - >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: users-h...@maven.apache.org >>>> >>>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
I am sorry if i cause the group to over-react about this real issue that i am here. I read the wiki page http://maven.apache.org/plugins/maven-deploy-plugin/usage.html three (or more) times now. I still not sure how to deploy older artifacts from local repository to remote repository without the need of recompiling older version of source code. It may be a simple thing to do. Am i missing something for the page? Or am i still not sure the usage? Or, the information is not from that page and need some people with the experience to answer? On Wed, Sep 22, 2010 at 11:07 PM, Anders Hammar wrote: > I second Wayne here. We'd be happy to help, but you have to do some job > yourself. > A pointer: look at the deploy-file goal of maven-deploy-plugin. > > /Anders > > On Thu, Sep 23, 2010 at 04:56, Wayne Fay wrote: > >> > If there are version 1.0.0.0, 2.0.0.0 and 3.0.0.0 of A in my local >> > repo. If I go to the location/workspace where I built A. If I type >> > "mvn deploy -Dversion=2.0.0.0, then will this deploy command deploy >> > the 2.0.0.0 from my local repository to remote repository without >> > re-building it? >> >> No, that will not work. >> >> Honestly, I give up until you go read the documentation and >> demonstrate that you've read it (and tried things yourself) before >> replying again. >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
If there are version 1.0.0.0, 2.0.0.0 and 3.0.0.0 of A in my local repo. If I go to the location/workspace where I built A. If I type "mvn deploy -Dversion=2.0.0.0, then will this deploy command deploy the 2.0.0.0 from my local repository to remote repository without re-building it? Thanks. A. On Wed, Sep 22, 2010 at 3:30 PM, Wayne Fay wrote: >> 1. Go to the machine with the local repository. >> 2. Do i need to go to the specific source tree or any place in the computer? >> 3. Type mvn deploy:deploy-file . > > Go read up on the deploy plugin... deploy:deploy-file takes a single > file as its argument, and deploys just that file to a specified remote > repo. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Can i re-deploy the contents from local repository from a build machine to release repository?
Just to be clear, you are saying: 1. Go to the machine with the local repository. 2. Do i need to go to the specific source tree or any place in the computer? 3. Type mvn deploy:deploy-file . Does the above command deploy the artifacts from local repository to remote repository as long as the settings.xml has the correct information about the remote repository? Thank you. A. On Wed, Sep 22, 2010 at 2:42 PM, Anders Hammar wrote: > There are several ways. I think the easiest is to use the deploy-file goal > of the deploy plugin. > > /Anders > > On Wed, Sep 22, 2010 at 23:20, baz themail wrote: > >> Hi, >> >> If the data in the remote release repository is corrupted and no >> backups. However, I found the artifacts in the local repository from a >> build machine. Can i re-deploy them into remote repository? How to do >> deploy a specific version like that without changing anything? Do i >> still need the source tree? >> >> Thanks. >> >> A. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can i re-deploy the contents from local repository from a build machine to release repository?
Hi, If the data in the remote release repository is corrupted and no backups. However, I found the artifacts in the local repository from a build machine. Can i re-deploy them into remote repository? How to do deploy a specific version like that without changing anything? Do i still need the source tree? Thanks. A. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: why I do not see the parent pom file in Nexus?
I am not sure what you meant by ".pom file". I am looking for a pom.xml which has the artifactId "parent-pom" and this should be the parent pom file for all project. I track down the whole groupId path in Nexus (both snapshot and release repositories). All I have found is the path composed of groupId and version, then no contents in the directory (In the Nexus view). Is this what you are referring to? "Because that's how pom.xml files get renamed when you're looking at a repo. You won't actually see "pom.xml" there" So, how can i verify the parent pom file in Nexus? Can you please explain the parent pom file deployment process? On Tue, Sep 21, 2010 at 2:03 PM, Bryan Loofbourrow wrote: > >>> -Original Message- > From: baz themail [mailto:bazthem...@gmail.com] > Sent: Tuesday, September 21, 2010 1:39 PM > To: Maven Users List > Subject: Re: why I do not see the parent pom file in Nexus? > > The path of groupId, artifactID, version is there. I just do not see > the pom.xml under it. This happens to both snapshot and release. All > builds are taking the right values and settings. I am assuming that > the parent pom has been deployed correctly to both release and > snapshot repositories. > > Is there any way that i can verify? << > > Are you looking for a .pom file? Because that's how pom.xml files get renamed > when you're looking at a repo. You won't actually see "pom.xml" there. > > -- Bryan > > > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > you may review at http://www.amdocs.com/email_disclaimer.asp > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: why I do not see the parent pom file in Nexus?
The path of groupId, artifactID, version is there. I just do not see the pom.xml under it. This happens to both snapshot and release. All builds are taking the right values and settings. I am assuming that the parent pom has been deployed correctly to both release and snapshot repositories. Is there any way that i can verify? On Tue, Sep 21, 2010 at 11:52 AM, Nayan Hajratwala wrote: > > On Sep 21, 2010, at 2:50 PM, baz themail wrote: > >> Hi, >> >> We are using Nexus here. I am pretty sure the parent pom file has been >> deployed and in use already. > > What makes you think it has already been deployed? Do you have output of the > parent pom build showing such? > > >> However, for some reason, I cannot see it >> in Nexus, why? How can i find it? >> >> Thank you. >> >> A. > > --- > Nayan Hajratwala > http://agileshrugged.com > http://twitter.com/nhajratw > 734.658.6032 > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
why I do not see the parent pom file in Nexus?
Hi, We are using Nexus here. I am pretty sure the parent pom file has been deployed and in use already. However, for some reason, I cannot see it in Nexus, why? How can i find it? Thank you. A. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can i test release plugin locally?
Nick, do you mean to branch out the existing code into a test branch? Any other ideas? On Thu, Sep 16, 2010 at 12:05 PM, Nick Stolwijk wrote: > To test release:prepare I usually use a branch or a local SVN > repostory. To test release:perform you can set the goals [1] to > install instead of deploy. > > [1] > http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html#goals > > Hth, > > Nick Stolwijk > ~Java Developer~ > > IPROFS BV. > Claus Sluterweg 125 > 2012 WS Haarlem > http://www.iprofs.nl > > > > On Thu, Sep 16, 2010 at 8:25 PM, baz themail wrote: >> The reason i want to dryRun and actual release in local repository is >> to make sure the module pom.xml files are being update correctly. >> Currently, I am having problem with incrementing the pom.xml file in >> one of the modules and not sure how to debug this. >> >> Can someone give me a sample where i can confirm the creation of new >> version'ed jar in both dryRun or actual log? >> >> On Thu, Sep 16, 2010 at 11:16 AM, baz themail wrote: >>> Another question. Is this possible to release into local repository >>> without giving SCM information such as P4 username and password? I do >>> not mean dryRun this time. >>> >>> On Thu, Sep 16, 2010 at 10:12 AM, baz themail wrote: >>>> Thanks for the replies. >>>> >>>> Yes, i know about DryRun. So, my question is: Does DryRun correctly >>>> run without SCM information such as P4 userid and password? >>>> >>>> Thanks. B. >>>> >>>> On Thu, Sep 16, 2010 at 7:47 AM, Nayan Hajratwala wrote: >>>>> On Sep 16, 2010, at 10:45 AM, baz themail wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> How can i test release plugin locally in my machine? Specifically, can >>>>>> i release the artifacts into my local repository on my machine? Can i >>>>>> configure it so that i do not need to make actual updates to pom files >>>>>> in perforce but only in local source tree? >>>>> >>>>> Have you tried the -DdryRun=true option? >>>>> http://maven.apache.org/plugins/maven-release-plugin/usage.html >>>>> >>>>> --- >>>>> Nayan Hajratwala >>>>> http://agileshrugged.com >>>>> http://twitter.com/nhajratw >>>>> 734.658.6032 >>>>> >>>>> >>>>> - >>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: users-h...@maven.apache.org >>>>> >>>>> >>>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can i test release plugin locally?
The reason i want to dryRun and actual release in local repository is to make sure the module pom.xml files are being update correctly. Currently, I am having problem with incrementing the pom.xml file in one of the modules and not sure how to debug this. Can someone give me a sample where i can confirm the creation of new version'ed jar in both dryRun or actual log? On Thu, Sep 16, 2010 at 11:16 AM, baz themail wrote: > Another question. Is this possible to release into local repository > without giving SCM information such as P4 username and password? I do > not mean dryRun this time. > > On Thu, Sep 16, 2010 at 10:12 AM, baz themail wrote: >> Thanks for the replies. >> >> Yes, i know about DryRun. So, my question is: Does DryRun correctly >> run without SCM information such as P4 userid and password? >> >> Thanks. B. >> >> On Thu, Sep 16, 2010 at 7:47 AM, Nayan Hajratwala wrote: >>> On Sep 16, 2010, at 10:45 AM, baz themail wrote: >>> >>>> Hi, >>>> >>>> How can i test release plugin locally in my machine? Specifically, can >>>> i release the artifacts into my local repository on my machine? Can i >>>> configure it so that i do not need to make actual updates to pom files >>>> in perforce but only in local source tree? >>> >>> Have you tried the -DdryRun=true option? >>> http://maven.apache.org/plugins/maven-release-plugin/usage.html >>> >>> --- >>> Nayan Hajratwala >>> http://agileshrugged.com >>> http://twitter.com/nhajratw >>> 734.658.6032 >>> >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> For additional commands, e-mail: users-h...@maven.apache.org >>> >>> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can i test release plugin locally?
Another question. Is this possible to release into local repository without giving SCM information such as P4 username and password? I do not mean dryRun this time. On Thu, Sep 16, 2010 at 10:12 AM, baz themail wrote: > Thanks for the replies. > > Yes, i know about DryRun. So, my question is: Does DryRun correctly > run without SCM information such as P4 userid and password? > > Thanks. B. > > On Thu, Sep 16, 2010 at 7:47 AM, Nayan Hajratwala wrote: >> On Sep 16, 2010, at 10:45 AM, baz themail wrote: >> >>> Hi, >>> >>> How can i test release plugin locally in my machine? Specifically, can >>> i release the artifacts into my local repository on my machine? Can i >>> configure it so that i do not need to make actual updates to pom files >>> in perforce but only in local source tree? >> >> Have you tried the -DdryRun=true option? >> http://maven.apache.org/plugins/maven-release-plugin/usage.html >> >> --- >> Nayan Hajratwala >> http://agileshrugged.com >> http://twitter.com/nhajratw >> 734.658.6032 >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How can i test release plugin locally?
Thanks for the replies. Yes, i know about DryRun. So, my question is: Does DryRun correctly run without SCM information such as P4 userid and password? Thanks. B. On Thu, Sep 16, 2010 at 7:47 AM, Nayan Hajratwala wrote: > On Sep 16, 2010, at 10:45 AM, baz themail wrote: > >> Hi, >> >> How can i test release plugin locally in my machine? Specifically, can >> i release the artifacts into my local repository on my machine? Can i >> configure it so that i do not need to make actual updates to pom files >> in perforce but only in local source tree? > > Have you tried the -DdryRun=true option? > http://maven.apache.org/plugins/maven-release-plugin/usage.html > > --- > Nayan Hajratwala > http://agileshrugged.com > http://twitter.com/nhajratw > 734.658.6032 > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to manage from snapshot to release? When should we use automated builds?
al list for the release, >> this appears to work. >> >> Ron >> >> >> On 15/09/2010 6:09 AM, Bengt Rodehav wrote: >> >>> Thanks for your input Baptiste, >>> >>> Yes, we have been debating the relase process a bit here. Keeping the >>> relase >>> process separate would e g mean that we know beforehand that we want to >>> build a release candidate. We could then start with the tagging and then >>> checkout on this tag for the build of the release candidate. >>> >>> Not quite sure what you mean by: >>> >>> (even if, imo, if you're depending on a snapshot revision, and try >>> >>> debugging a snapshot version that's not the dev version, you have a >>> problem >>> >>> in your dev process) >>> >>> >>> Our central, nightly builds do not use published snapshots but always >>> checks >>> out from CVS and then build from source. I agree that if a central build >>> (that could be a release candidate) was built using published snapshots, >>> we >>> would have a problem. >>> >>> /Bengt >>> >>> >>> 2010/9/15 Baptiste MATHUS >>> >>> Yes, this is a typical, almost specific CVS problem that's >>>> understandable. >>>> As the versioning is done at the file level, and not at the repo one, it >>>> can >>>> be necessary to tag to be able to identify the code corresponding to a >>>> snapshot (even if, imo, if you're depending on a snapshot revision, and >>>> try >>>> debugging a snapshot version that's not the dev version, you have a >>>> problem >>>> in your dev process). >>>> >>>> This problem doesn't exist with SVN. For example, we use the >>>> buildnumber-maven-plugin and add the svn repository revision number to >>>> the >>>> manifest for each build. So finding corresponding code for a jar is no >>>> problem at all for us, but we actually hardly need it. >>>> >>>> For the dev process, only in my opinion, I think automatically releasing >>>> every nights isn't a very good pratice. I rather think the release >>>> process >>>> should be actually 100% standalone, but *manually* initiated (giving the >>>> new >>>> version and so). >>>> >>>> Cheers >>>> >>>> 2010/9/15 Bengt Rodehav >>>> >>>> We've had similar questions where I work. The question has been related >>>>> >>>> to >>>> >>>>> how and when to create tags in CVS (preferrably using the >>>>> maven-release-plugin). >>>>> >>>>> Some people advocate tagging every build so that it can be recreated in >>>>> case >>>>> it was fit for delivery. This is a problem when using CVS since huge >>>>> >>>> number >>>> >>>>> of tags are not handled very well. >>>>> >>>>> However, builds that could potentially become a released version must be >>>>> recreatable somehow which implies a tag in the version control system. >>>>> Whenever a "release candidate" is built, doesn't it have to be tagged - >>>>> >>>> and >>>> >>>>> therefore released? >>>>> >>>>> When we enter a system testing period close to the release of a new >>>>> version. >>>>> We normally build and deploy new versions automatically every day. At >>>>> >>>> some >>>> >>>>> point we decide that it's good enough to release. It is then imperative >>>>> that >>>>> the latest build (which we have used for testing) is the one we package >>>>> >>>> and >>>> >>>>> tag. >>>>> >>>>> What are the best practices around this? I'm very curious to know how >>>>> >>>> other >>>> >>>>> organisations handle this using maven. >>>>> >>>>> /Bengt >>>>> >>>>> >>>>> 2010/9/15 Baptiste MATHUS >>>>> >>>>> Well, for example, we don't release automatically. We launch manually >>>>>> >>>>> it >>>> >>>>> via a
How can i test release plugin locally?
Hi, How can i test release plugin locally in my machine? Specifically, can i release the artifacts into my local repository on my machine? Can i configure it so that i do not need to make actual updates to pom files in perforce but only in local source tree? Thank you. A. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to manage from snapshot to release? When should we use automated builds?
Hi, I have been searching the maven website and articles but not sure if i get the best practice for managing snapshots and release. Specifically, if continuous builds produce maven snapshot builds, then when will i produce maven release builds using maven release plug-in? Will I ever produce a maven release build via an automated build job that runs daily for example? The problem with that is: Because maven plugin is incrementing pom.xml, and the automated build job will always detect changes even tho there is no changes in the produce software code. Does it even make sense? Or, release build should be run manually depending on the release schedule? Thank you. A. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
