maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: New snapshots versus the local repo
Date Tue, 16 Mar 2010 14:37:19 GMT
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


Mime
View raw message