I also say move it out, but re-open the ticket for 3.x. It's possible the resolution is correct, and people's procedures are wrong, but give it time for the debate to live out. More thought should go into this before closing it as Won't Fix.
Paul On Wed, Dec 16, 2009 at 4:40 PM, Jason van Zyl <ja...@sonatype.com> wrote: > + 1 For pulling it out > > On 2009-12-16, at 2:38 PM, Brian Fox wrote: > >> For all the potential trouble this "enhancement" causes, does it >> really have a justifiable performance boost? I mean is copying a pom >> really that slow given everything else that has to happen in parallel? >> >> I know if I go to a folder and run mvn install, I expect THOSE EXACT >> products from this build to be in my local repo regardless of what >> conflicts I may have with other branches. It's not reasonable to >> expect a developer to bump all their versions just because they've >> made a branch, particularly if it's a short lived and not-shared with >> other developers. >> >> I'm in favor of pulling this back or changing it to check for exact >> timestamp and size. >> >> On Wed, Dec 9, 2009 at 10:49 AM, Dan Tran <dant...@gmail.com> wrote: >>> and It is very tough or nearly impossible to ask developers 40+ to do the >>> workaround below. >>> >>> -Dan >>> >>> On Wed, Dec 9, 2009 at 7:44 AM, Dan Tran <dant...@gmail.com> wrote: >>>> oh mine I am so glad accidentally read this. My team doing this so >>>> offen, by doing a quick branch an merge the change back >>>> how ever sometimes, it would some time to start the merge. >>>> >>>> so there are 2 solutions: >>>> >>>> - change the version >>>> or >>>> - each branch has its own local. >>>> >>>> This is very annoying and confusing. And I am sure it may be chaotic >>>> for some teams when starting using mvn 2.2 or 3.0 where the change >>>> happens >>>> >>>> Please revert it, or make it an option on command line ( like -Ol etc ) >>>> >>>> Thanks >>>> >>>> 2009/12/9 Tamás Cservenák <ta...@cservenak.net>: >>>>> Hi there, >>>>> >>>>> Just to refresh memories, there is an interesting debate going on: >>>>> >>>>> http://jira.codehaus.org/browse/MNG-4368 >>>>> >>>>> BTW, now I do realize that the issue I thought to be my problem, and is >>>>> used >>>>> to exchange comments are not the same.... >>>>> But the problem is still a problem. >>>>> >>>>> Thanks, >>>>> ~t~ >>>>> >>>>> On Mon, Dec 7, 2009 at 4:05 PM, Arnaud HERITIER <aherit...@gmail.com> >>>>> wrote: >>>>> >>>>>> I agree to fix the behavior like you propose Paul. >>>>>> It will reduce probably a little bit current performances but if it >>>>>> solves >>>>>> the case explained by Tamas, why not ... >>>>>> >>>>>> >>>>>> On Mon, Dec 7, 2009 at 4:01 PM, Paul Gier <pg...@redhat.com> wrote: >>>>>> >>>>>>> It seems that the copyFileIfModified implementation should be changed. >>>>>>> Since currently it only checks if the source timestamp is newer. Maybe >>>>>>> this should be changed to check for the timestamps not equal (and maybe >>>>>> size >>>>>>> not equal also) instead of just a newer timestamp. That would allow the >>>>>>> optimization, but also handle the use case described in the jira issue. >>>>>>> >>>>>>> >>>>>>> Tamás Cservenák wrote: >>>>>>> >>>>>>>> Well, how about a "feature branch" (short lived branches)? Or you >>>>>>>> modify >>>>>>>> all >>>>>>>> the modules to have different GAV upon branch? This is kinda nonsense >>>>>>>> to >>>>>>>> me, >>>>>>>> since I branch it to do some feature that I know will get back into >>>>>> trunk. >>>>>>>> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in >>>>>> this >>>>>>>> case, IMHO. >>>>>>>> >>>>>>>> But even then, I dislike very much the idea that Maven "optimizes" >>>>>>>> this, >>>>>>>> and >>>>>>>> does less then I tell it to do ;) >>>>>>>> >>>>>>>> ~t~ >>>>>>>> >>>>>>>> On Mon, Dec 7, 2009 at 3:18 PM, Arnaud HERITIER <aherit...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> You have the same version in 2 branches in a project ? >>>>>>>>> For me it is a bad practice >>>>>>>>> Each branch has it own version to avoid those sort of conflict. >>>>>>>>> >>>>>>>>> >>>>>>>>> Arnaud Héritier >>>>>>>>> Software Factory Manager >>>>>>>>> eXo platform - http://www.exoplatform.com >>>>>>>>> --- >>>>>>>>> http://www.aheritier.net >>>>>>>>> >>>>>>>>> >>>>>>>>> 2009/12/7 Tamás Cservenák <ta...@cservenak.net> >>>>>>>>> >>>>>>>>> Hi there, >>>>>>>>>> >>>>>>>>>> this is mainly about this issue: >>>>>>>>>> http://jira.codehaus.org/browse/MNG-4368 >>>>>>>>>> >>>>>>>>>> It caused a lot of grief (and lost hours) to me, until I figured what >>>>>>>>>> happens on me. >>>>>>>>>> >>>>>>>>>> IMHO, no "optimization" like this should be done against local >>>>>>>>>> >>>>>>>>> repository. >>>>>>>>> >>>>>>>>>> Please undo it. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> ~t~ >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
