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 <[email protected]> wrote: > On Tue, Mar 16, 2010 at 11:18 AM, Maven User <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>>> <[email protected]> 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 <[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] >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
