You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2010/03/16 02:10:04 UTC
New snapshots versus the local repo
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.
Without patching all the version numbers, is there a best practice or
standard mechanism to stay out of this pickle?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: New snapshots versus the local repo
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Mar 16, 2010 at 4:18 AM, Benson Margulies <bi...@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
> <st...@gmail.com> wrote:
>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Stephen Connolly <st...@gmail.com>.
On 16 March 2010 14:37, Benson Margulies <bi...@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?
>
>
have a look at versions-maven-plugin@mojo might do some of what you want
> 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 <ma...@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
> > <st...@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 <ma...@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 <bi...@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
> >>>> <st...@gmail.com> wrote:
> >>>>
> >>>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
>
>
Re: New snapshots versus the local repo
Posted by Wayne Fay <wa...@gmail.com>.
> No tool is going to insulate you from bad human management practices.
> If 2 people are writing the same software module, they have to work to the
> same spec and coordinate themselves.
Ron nailed it. Communication is key!!
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: New snapshots versus the local repo
Posted by Ron Wheeler <rw...@artifact-software.com>.
Benson Margulies wrote:
> On Tue, Mar 16, 2010 at 11:18 AM, Maven User <ma...@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.
>
But you want the new improved "a" since it should include your changes
and the improvements from the other person if you are using a SCM system
and communicating with the other people changing it.
No tool is going to insulate you from bad human management practices.
If 2 people are writing the same software module, they have to work to
the same spec and coordinate themselves.
Ron
>
>
>>
>> On Mar 16, 2010, at 10:37 AM, Benson Margulies <bi...@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 <ma...@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
>>>> <st...@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 <ma...@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 <bi...@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
>>>>>>> <st...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Brian Fox <br...@infinity.nu>.
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
<bi...@gmail.com> wrote:
> On Tue, Mar 16, 2010 at 11:18 AM, Maven User <ma...@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 <bi...@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 <ma...@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
>>>> <st...@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 <ma...@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 <bi...@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
>>>>>>> <st...@gmail.com> wrote:
>>>>>>>
>>>>>>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Mar 16, 2010 at 11:18 AM, Maven User <ma...@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 <bi...@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 <ma...@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
>>> <st...@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 <ma...@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 <bi...@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
>>>>>> <st...@gmail.com> wrote:
>>>>>>
>>>>>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Maven User <ma...@gmail.com>.
But then shouldn't you be building with what's available, not a
snapshot created at some other time,
On Mar 16, 2010, at 10:37 AM, Benson Margulies <bi...@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 <ma...@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
>> <st...@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 <ma...@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
>>>>> <st...@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
Re: New snapshots versus the local repo
Posted by Benson Margulies <bi...@gmail.com>.
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 <ma...@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
> <st...@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 <ma...@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 <bi...@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
>>>> <st...@gmail.com> wrote:
>>>>
>>>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Maven User <ma...@gmail.com>.
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 <ma...@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 <bi...@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
>>> <st...@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
Re: New snapshots versus the local repo
Posted by Stephen Connolly <st...@gmail.com>.
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 <ma...@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 <bi...@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
>> <st...@gmail.com> wrote:
>>
>>> On 16 March 2010 04:25, Ron Wheeler <rw...@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
>
>
Re: New snapshots versus the local repo
Posted by Maven User <ma...@gmail.com>.
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 <bi...@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
> <st...@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
Re: New snapshots versus the local repo
Posted by Benson Margulies <bi...@gmail.com>.
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
<st...@gmail.com> wrote:
> On 16 March 2010 04:25, Ron Wheeler <rw...@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
Re: New snapshots versus the local repo
Posted by Stephen Connolly <st...@gmail.com>.
On 16 March 2010 04:25, Ron Wheeler <rw...@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
>
>
Re: New snapshots versus the local repo
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.
>
> 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