You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Tamás Cservenák <ta...@cservenak.net> on 2009/12/07 15:06:28 UTC
Local Repository Optimizations should be removed
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~
Re: Local Repository Optimizations should be removed
Posted by Paul Benedict <pb...@apache.org>.
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 <da...@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 <da...@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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Jason van Zyl <ja...@sonatype.com>.
+ 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 <da...@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 <da...@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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Ralph Goers <ra...@dslextreme.com>.
On Dec 16, 2009, 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.
+1
Ralph
>
> On Wed, Dec 9, 2009 at 10:49 AM, Dan Tran <da...@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 <da...@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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Stephen Connolly <st...@gmail.com>.
but with these optimizations, the jar plugin could decide not to
repackage as all the files it would add have the same size and
timestamp as inside the jar
without these opts such an optimization is of less use
Sent from my [rhymes with tryPod] ;-)
On 28 Dec 2009, at 14:06, Igor Fedorenko <ig...@ifedorenko.com> wrote:
>
> Benjamin Bentmann wrote:
>> Igor Fedorenko wrote:
>>> Out of curiosity, what kind of performance difference you get with
>>> this
>>> optimization vs without it?
>> I did not benchmark this. This is about IO, so pick a module count,
>> an average artifact size and IO throughput.
>
> From my experience, "feeling" about performance often do not match the
> reality, so you really need to support them by specific numbers,
> either
> calculated or obtained during experiment (or both). For example, I can
> argue that all artifacts are rebuilt during each build, so they will
> get
> new timestamps and thus will be reinstalled each time. But this is
> again
> a guess, and does not carry any more weight unless I support it with
> an experiment ;-)
>
>>> Also, I think implementation should behave the same for pom and
>>> other
>>> artifacts. I would not want to have to troubleshoot "strange" build
>>> failures should pom get out of sync with the rest.
>> I merely tried to realize a compromise based on some ideas in this
>> thread. Feel free to veto it or revise it, my heart is not hanging
>> on this.
>
> Sorry, I did not mean to sound prescriptive. This is just another
> idea you may choose to consider or ignore.
>
> --
> Regards,
> Igor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Benjamin Bentmann <be...@udo.edu>.
Igor Fedorenko wrote:
> Sorry, I did not mean to sound prescriptive. This is just another
> idea you may choose to consider or ignore.
Yeah, I got that :-) My previous short answer was just intended to
express my lack of interest in a long discussion about this topic. The
special handling for POMs I applied was to account for oddities that
Tamás has previously described.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Benjamin Bentmann wrote:
> Igor Fedorenko wrote:
>
>> Out of curiosity, what kind of performance difference you get with this
>> optimization vs without it?
>
> I did not benchmark this. This is about IO, so pick a module count, an
> average artifact size and IO throughput.
From my experience, "feeling" about performance often do not match the
reality, so you really need to support them by specific numbers, either
calculated or obtained during experiment (or both). For example, I can
argue that all artifacts are rebuilt during each build, so they will get
new timestamps and thus will be reinstalled each time. But this is again
a guess, and does not carry any more weight unless I support it with
an experiment ;-)
>
>> Also, I think implementation should behave the same for pom and other
>> artifacts. I would not want to have to troubleshoot "strange" build
>> failures should pom get out of sync with the rest.
>
> I merely tried to realize a compromise based on some ideas in this
> thread. Feel free to veto it or revise it, my heart is not hanging on this.
Sorry, I did not mean to sound prescriptive. This is just another
idea you may choose to consider or ignore.
--
Regards,
Igor
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Benjamin Bentmann <be...@udo.edu>.
Igor Fedorenko wrote:
> Out of curiosity, what kind of performance difference you get with this
> optimization vs without it?
I did not benchmark this. This is about IO, so pick a module count, an
average artifact size and IO throughput.
> Also, I think implementation should behave the same for pom and other
> artifacts. I would not want to have to troubleshoot "strange" build
> failures should pom get out of sync with the rest.
I merely tried to realize a compromise based on some ideas in this
thread. Feel free to veto it or revise it, my heart is not hanging on this.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Dan Fabulich <da...@fabulich.com>.
Igor Fedorenko wrote:
> Out of curiosity, what kind of performance difference you get with this
> optimization vs without it?
I originally checked this in because it made a huge difference at my
organization. My goal was to reduce the time required to do a "no op"
build.
Our multi-module build creates several WAR files that are ~20MB each. In
the case where the war hadn't changed, those files were being copied
unnecessarily.
Before the changes a "no op" build took more than a minute to accomplish
nothing; after the changes the build got down below 30 seconds.
I agree with Benjamin's more sophisticated timestamp/size checking. I'm
-0 on the special treatment of POM files.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Arnaud HERITIER <ah...@gmail.com>.
If we want to study the impact on performances, I think we have to create a
test case with a project creating wars and ears of several dozen of Mb.
I already saw some projects like that (an EAR of 100Mb with 2 wars of 50Mb).
Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net
On Mon, Dec 28, 2009 at 2:47 AM, Igor Fedorenko <ig...@ifedorenko.com> wrote:
> Benjamin,
>
> Out of curiosity, what kind of performance difference you get with this
> optimization vs without it?
>
> Also, I think implementation should behave the same for pom and other
> artifacts. I would not want to have to troubleshoot "strange" build
> failures should pom get out of sync with the rest.
>
> --
> Regards,
> Igor
>
>
>
> Benjamin Bentmann wrote:
>
>> Brian Fox wrote:
>>
>> I'm in favor of pulling this back or changing it to check for exact
>>> timestamp and size.
>>>
>>
>> I consider both the workflow outlined by Tamás and the need for
>> optimization valid points so instead of pulling it out completely I opted to
>> improve the existing logic. In the next alpha of Maven 3.0, artifact
>> installation is only skipped if all of the following conditions hold:
>> * destination has exact same timestamp as source
>> * destination has exact same length as source
>> * artifact is not of type "pom"
>>
>>
>> Benjamin
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Local Repository Optimizations should be removed
Posted by Igor Fedorenko <ig...@ifedorenko.com>.
Benjamin,
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
Also, I think implementation should behave the same for pom and other
artifacts. I would not want to have to troubleshoot "strange" build
failures should pom get out of sync with the rest.
--
Regards,
Igor
Benjamin Bentmann wrote:
> Brian Fox wrote:
>
>> I'm in favor of pulling this back or changing it to check for exact
>> timestamp and size.
>
> I consider both the workflow outlined by Tamás and the need for
> optimization valid points so instead of pulling it out completely I
> opted to improve the existing logic. In the next alpha of Maven 3.0,
> artifact installation is only skipped if all of the following conditions
> hold:
> * destination has exact same timestamp as source
> * destination has exact same length as source
> * artifact is not of type "pom"
>
>
> Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Benjamin Bentmann <be...@udo.edu>.
Brian Fox wrote:
> I'm in favor of pulling this back or changing it to check for exact
> timestamp and size.
I consider both the workflow outlined by Tamás and the need for
optimization valid points so instead of pulling it out completely I
opted to improve the existing logic. In the next alpha of Maven 3.0,
artifact installation is only skipped if all of the following conditions
hold:
* destination has exact same timestamp as source
* destination has exact same length as source
* artifact is not of type "pom"
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Brian Fox <br...@infinity.nu>.
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 <da...@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 <da...@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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>>> >
>>>> >
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Dan Tran <da...@gmail.com>.
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 <da...@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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>> >
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Dan Tran <da...@gmail.com>.
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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by 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 <ah...@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 <ah...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
Re: Local Repository Optimizations should be removed
Posted by Arnaud HERITIER <ah...@gmail.com>.
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 <ah...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Local Repository Optimizations should be removed
Posted by Paul Gier <pg...@redhat.com>.
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 <ah...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Local Repository Optimizations should be removed
Posted by Arnaud HERITIER <ah...@gmail.com>.
ok. I don't know enough GIT and DSCMs.
I understand that many people want to work on various branches but I find
that dangerous if you kkep the same version.
What happens if you deploy SNAPSHOTs binairies in a repository to do
continuous integration ?
About your problem of optimization, I could understand we need to add a
switch to deactivate it in cases like yours. But I'm not in favor to remove
it. Your usecase (switching between several branches with the same "maven
version") isn't "common" and the gain given by the optimization is
important. I think that we need more optimizations like that to redo the
minimal number of things (like we did many many years ago with make).
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>
> Okay, let's put it this way:
>
> are you saying that all the different GIT reposes out there containing
> "project A" mirrors should have different versions? Who will coordinate
> those?
>
> It's somehow incompatible with Git (and probably any other distributed SCM)
> in very fundamental way....
>
> ~t~
>
> On Mon, Dec 7, 2009 at 3:30 PM, Arnaud HERITIER <ah...@gmail.com>
> wrote:
>
> > ...
> > "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in
> this
> > case, IMHO.
> > ...
> > mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT
> >
> > And it's done ?
> >
> >
> > 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>
> >
> > > 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 <ah...@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~
> > > > >
> > > >
> > >
> >
>
Re: Local Repository Optimizations should be removed
Posted by Tamás Cservenák <ta...@cservenak.net>.
Okay, let's put it this way:
are you saying that all the different GIT reposes out there containing
"project A" mirrors should have different versions? Who will coordinate
those?
It's somehow incompatible with Git (and probably any other distributed SCM)
in very fundamental way....
~t~
On Mon, Dec 7, 2009 at 3:30 PM, Arnaud HERITIER <ah...@gmail.com> wrote:
> ...
> "Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
> case, IMHO.
> ...
> mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT
>
> And it's done ?
>
>
> 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>
>
> > 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 <ah...@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~
> > > >
> > >
> >
>
Re: Local Repository Optimizations should be removed
Posted by Arnaud HERITIER <ah...@gmail.com>.
...
"Renaming" (changing GAVs of modules, maybe a LOT of them) is PITA in this
case, IMHO.
...
mvn versions:set -DnewVersion=A.B.C-optim-SNAPSHOT
And it's done ?
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>
> 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 <ah...@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~
> > >
> >
>
Re: Local Repository Optimizations should be removed
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ah...@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~
> >
>
Re: Local Repository Optimizations should be removed
Posted by Arnaud HERITIER <ah...@gmail.com>.
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~
>