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 buil
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 PO
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
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"
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
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.exop
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 res
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
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
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 wr
+ 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
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
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 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
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
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, D
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 wrote:
> It seems that the copyFileIfModified implementation should be changed.
> Sin
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 un
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 op
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,
...
"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 Cser
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
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
> Hi the
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~
23 matches
Mail list logo
