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 <[email protected]> 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 <[email protected]> > 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 >> <[email protected]> wrote: >> >>> On 16 March 2010 04:25, Ron Wheeler <[email protected]> >>> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
