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]
