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 <nick.stolw...@gmail.com> 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 <bazthem...@gmail.com> 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 <nick.stolw...@gmail.com> 
>> 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 <bazthem...@gmail.com> 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 <nick.stolw...@gmail.com> 
>>>> 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 <bazthem...@gmail.com> 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)
>>>>>> <tthies...@avaya.com> 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 <wsm...@gmail.com> wrote:
>>>>>>>> > On Tue, Jan 4, 2011 at 12:28 PM, baz themail <bazthem...@gmail.com>
>>>>>>>> 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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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

Reply via email to