maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kalle Korhonen <kalle.o.korho...@gmail.com>
Subject Re: New snapshots versus the local repo
Date Tue, 16 Mar 2010 12:54:47 GMT
On Tue, Mar 16, 2010 at 4:18 AM, Benson Margulies <bimargulies@gmail.com> wrote:
> 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.

Offline is the answer short of a branch. In any maintained and stable
build, there should generally be no other snapshot dependencies than
your project own ones. Using external snapshot dependencies should be
an exception rather than a rule.

Kalle

> 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
View raw message