maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: Fast or exact ?
Date Tue, 12 Feb 2013 18:49:36 GMT
> So if you want to make an example, use a separate profile.
>

No more freaking profiles, please! Either configure it for all build
executions, or don't configure it at all!

/Anders


>
> thanks,
>
> Robert
>
>
> Op Mon, 11 Feb 2013 21:26:35 +0100 schreef Stephen Connolly <
> stephen.alan.connolly@gmail.**com <stephen.alan.connolly@gmail.com>>:
>
>  You miss my point. Give an example of how to configure such a release
>> profile. Plus how would recompression being on break things? Is the jar
>> spec that weak?
>>
>> On Monday, 11 February 2013, Anders Hammar wrote:
>>
>>  > Given that people don't do applets any more, and most app servers
>>> explode
>>> > the .wars anyway, speed should be king. I'd give an example of turning
>>> it
>>> > on for the release profile though on the project site
>>> >
>>>
>>> I don't think having a different setting for releases than for the
>>> snapshots is a good idea. My experience is that very few are using
>>> staging,
>>> so they will be testing the snapshots and then trust the release to be
>>> the
>>> same. Which it wouldn't in this case. Sure, not doing some kind of
>>> staging/QA is bad practice but people seem to not listen to that
>>> advice...
>>>
>>> /Anders
>>>
>>>
>>>
>>> >
>>> > On Monday, 11 February 2013, Romain Manni-Bucau wrote:
>>> >
>>> > > I think today we care more about time than size (it shouldn't be gigs
>>> ;)
>>> > >
>>> > > wdyt?
>>> > >
>>> > > *Romain Manni-Bucau*
>>> > > *Twitter: @rmannibucau <https://twitter.com/**rmannibucau<https://twitter.com/rmannibucau>
>>> >*
>>> > > *Blog: **http://rmannibucau.**wordpress.com/*<http://rmannibucau.wordpress.com/*>
>>> <
>>> > > http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>>> >
>>> > > *LinkedIn: **http://fr.linkedin.com/in/**rmannibucau*<http://fr.linkedin.com/in/rmannibucau*>
>>> > > *Github: https://github.com/**rmannibucau*<https://github.com/rmannibucau*>
>>> > >
>>> > >
>>> > >
>>> > > 2013/2/11 Kristian Rosenvold <kristian.rosenvold@gmail.com<**
>>> javascript:;>
>>> <javascript:;>>
>>> > >
>>> > > > The "fast" mode is twice as fast at "slow", which I see quite
a few
>>> > > people
>>> > > > enjoy (these plugins can be quite slow). Initially I measured
the
>>> > > increase
>>> > > > in size to be 3-5%, which was why I just flipped default to "fast".
>>> It
>>> > > > turned out the projects I measured were rather best-case, and
a
>>> little
>>> > > more
>>> > > > experience seems to indicate a 10-15% size increase being more
of
>>> the
>>> > > norm.
>>> > > >
>>> > > > So I have flipped the default back to "slow". Which mode is "best"
>>> > > depends
>>> > > > largely  on your perspective ;) I'd say fast beats slow any day
of
>>> the
>>> > > > week, but I think 10-15% is a bit too much ;)
>>> > > >
>>> > > > BTW; The main part of the increase is actually caused by some
jars
>>> in
>>> > > > central having little or no compression applied to them. There
>>> might
>>> be
>>> > > > room for making the compression header sniffing even smarter
>>> > (recompress
>>> > > if
>>> > > > all files in the zip have "stored" compression type; should be
>>> possible
>>> > > to
>>> > > > implement with only performance loss for those few files).
>>> > > >
>>> > > > If anyone wants to have a shot at that I'll happily review such
a
>>> patch
>>> > > ;)
>>> > > >
>>> > > > Kristian
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> > > > 2013/2/8 Romain Manni-Bucau <rmannibucau@gmail.com<javascript:;><javascript:;>>
>>> > > >
>>> > > > > Hi guys,
>>> > > > >
>>> > > > > do you have figures regarding size and execution time?
>>> slower/bigger
>>> > > > > doesn't speak that much to help to choose a default config
;)
>>> > > > >
>>> > > > > *Romain Manni-Bucau*
>>> > > > > *Twitter: @rmannibucau <https://twitter.com/**rmannibucau<https://twitter.com/rmannibucau>
>>> >*
>>> > > > > *Blog: **http://rmannibucau.**wordpress.com/*<http://rmannibucau.wordpress.com/*>
>>> <
>>> > > > > http://rmannibucau.wordpress.**com/<http://rmannibucau.wordpress.com/>
>>> >
>>> > > > > *LinkedIn: **http://fr.linkedin.com/in/**rmannibucau*<http://fr.linkedin.com/in/rmannibucau*>
>>> > > > > *Github: https://github.com/**rmannibucau*<https://github.com/rmannibucau*>
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > 2013/2/8 Anders Hammar <anders@hammar.net<javascript:;><javascript:;>>
>>> > > > >
>>> > > > > > In general, I think that the default value should be
whatever
>>> works
>>> > > in
>>> > > > > most
>>> > > > > > cases. Then we could have params for tweaking this (for
better
>>> > > > > performance
>>> > > > > > e.g. in specific cases), but it would be up to the user
to do
>>> this.
>>> > > > > > So, in this specific case, I think the default should
be to
>>> > > recompress
>>> > > > so
>>> > > > > > that it always works even though it might be a bit slower.
>>> > > > > >
>>> > > > > > /Anders
>>> > > > > >
>>> > > > > >
>>> > > > > > On Thu, Feb 7, 2013 at 9:58 PM, Kristian Rosenvold <
>>> > > > > > kristian.rosenvold@gmail.com <javascript:;> <javascript:;>>
>>> wrote:
>>> > > > > >
>>> > > > > > > A lot of you seemed to have realized that the latest
version
>>> of
>>> > war
>>> > > > and
>>> > > > > > > assembly have chosen the "fast" option over the
"compact"
>>> option;
>>> > > and
>>> > > > > you
>>> > > > > > > actually seem to like it ;)
>>> > > > > > >
>>> > > > > > > https://jira.codehaus.org/**browse/MASSEMBLY-639<https://jira.codehaus.org/browse/MASSEMBLY-639>has
been filed
>>> > and
>>> > > > > > "fixed"
>>> > > > > > > which will revert the behaviour back to "slow"
for both war
>>> and
>>> > > > > assembly,
>>> > > > > > > So what do you think ?
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > Kristian
>>> > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<dev-unsubscribe@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message