maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Fox <bri...@infinity.nu>
Subject Re: New snapshots versus the local repo
Date Tue, 16 Mar 2010 16:08:00 GMT
Disable automatic snapshot checking (this is the default in M3) and
then you're fine. Nothing changes until you ask for updates.

On Tue, Mar 16, 2010 at 11:32 AM, Benson Margulies
<bimargulies@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 11:18 AM, Maven User <maven.2.user@gmail.com> wrote:
>> But then shouldn't you be building with what's available, not a snapshot
>> created at some other time,
>
> At time 0, I build everything. Components a, b, c, d. At time 1, a new
> snapshot arrives for component a, and unless i go back and run mvn
> clean install on (a), it replaces my local build.
>
>
>>
>>
>>
>> On Mar 16, 2010, at 10:37 AM, Benson Margulies <bimargulies@gmail.com>
>> wrote:
>>
>>> Just for fun, I think it's worth explaining the environment.
>>>
>>> We are relatively new adopters of Maven. Up until now, we've done
>>> maven releases only for external product releases. Thus, there are
>>> snapshot dependencies amongst our internal components for months on
>>> end. To make my original scenario a trifle more concrete:
>>>
>>> I'm plugging away at a set of changes. The changes are across several
>>> aggregated components. I finish with one component, and I'm working on
>>> the next.
>>>
>>> The overall set isn't going to be done in a day, but they feel really
>>> light for a branch. Meanwhile, one of my colleagues knocks off a small
>>> fix in the component I've finished with. So, she checks in, hudson
>>> builds, and produces a snapshot. Unless I go back and rebuild my copy
>>> of that component, I get a surprise.
>>>
>>> Say that we tried to address this by making internal releases and only
>>> using snapshot dependencies 'locally,' to a build tree. Is there a
>>> plugin that will auto-edit a tree, finding all dependencies on g/a/v
>>> x:y:26 and replacing them with x:y:27-SNAPSHOT? And then put them back
>>> for checkin?
>>>
>>> My fantasy continues to be that I could put a filter in my
>>> settings.xml that turned off snapshot updates on a set of g/a/v
>>> patterns.
>>>
>>>
>>>
>>>
>>> On Tue, Mar 16, 2010 at 9:00 AM, Maven User <maven.2.user@gmail.com>
>>> wrote:
>>>>
>>>> You could probably do a dependency:resolve and leverage the
>>>> includes/excludes - but that starts smelling hacky.
>>>>
>>>> I'm in agreement with the earlier comment.  If you're allowing any/all
>>>> devs
>>>> to deploy, it can't be a free-for-all.
>>>>
>>>> Why not let ci be the bottleneck (which implicitly has some degree of
>>>> automated testing)?  Devs have the option of deactivating tests
>>>> locally....
>>>>
>>>> On Mar 16, 2010, at 8:52 AM, Stephen Connolly
>>>> <stephen.alan.connolly@gmail.com> wrote:
>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>

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


Mime
View raw message