On 16 March 2010 14:37, 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? > > have a look at versions-maven-plu...@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 <[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] > >
