maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: New snapshots versus the local repo
Date Tue, 16 Mar 2010 12:52:40 GMT
I guess the issue is if you want to update some but not all of your
-SNAPSHOT dependencies. Maven does not provide filtering of update checking

On 16 March 2010 12:46, Maven User <maven.2.user@gmail.com> wrote:

> Google maven updatepolicy - you (as a user) can choose how often (or at
> all) you take versions from a repository.
>
>
> On Mar 16, 2010, at 8:18 AM, Benson Margulies <bimargulies@gmail.com>
> wrote:
>
>  Well, at least now we can see the disconnect. People don't want to
>> make a branch every time they are working on something for more than a
>> day. (Default snapshot update is a day.) Making a branch is fairly
>> tiresome, especially given the difficulty of persuading release:branch
>> to work. The 'person' who published the snapshot is hudson, just doing
>> its job.
>>
>> If the answer is, 'always make a branch,' then that's the answer. It
>> is not a popular answer with the developers I'm supporting. I wish
>> there was some alternative involving controlling snapshot updates per
>> g/a instead of per repository. --offline prevents unwanted updates,
>> but it also prevents wanted updates of other, unmodified, things, and
>> new dependencies.
>>
>>
>> On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly
>> <stephen.alan.connolly@gmail.com> wrote:
>>
>>> On 16 March 2010 04:25, Ron Wheeler <rwheeler@artifact-software.com>
>>> wrote:
>>>
>>>  Benson Margulies wrote:
>>>>
>>>>  I have this feeling that I'm missing something terribly obvious.
>>>>>
>>>>> 1: grab a tree and make some changes.
>>>>> 2: mvn. Now you've got SNAPSHOT versions in your local repository
>>>>> 3: someone else checks in a change and runs mvn deploy. Now the
>>>>> snapshot repo has jars newer than the local repo.
>>>>>
>>>>
>>>> 4: run mvn and download those over top of the local mods.
>>>>
>>>>>
>>>>>
>>>>  Only if you have the update rule for your snapshot repos set to check
>>> every
>>> time.
>>>
>>> If you are working on a branch, then run maven in offline mode to prevent
>>> having to worry about picking up other versions that somebody elese has
>>> deployed
>>>
>>>
>>>
>>>>  Without patching all the version numbers, is there a best practice or
>>>>> standard mechanism to stay out of this pickle?
>>>>>
>>>>>
>>>>>  What is the pickle? You have the latest version which is what you want
>>>> if
>>>> the person doing the deploy has done the deploy for a reason.
>>>> If the version deployed is not better than the version that you have
>>>> locally, you beat the crap out of the guy who deployed a version when
>>>> they
>>>> shouldn't have.
>>>>
>>>> If people deploy crap into repositories, you will have a problem
>>>> eventually.
>>>> If you put your version into your source management, the other person
>>>> would
>>>> have based his mods on yours or at least noticed the conflicts before he
>>>> deployed.
>>>>
>>>> Collaborative software development has to be done collaboratively.
>>>>
>>>> Ron
>>>>
>>>>
>>>>  ---------------------------------------------------------------------
>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>
>> ---------------------------------------------------------------------
>> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message