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 <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
