> 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>*
> > *Blog: **http://rmannibucau.wordpress.com/*<
> > http://rmannibucau.wordpress.com/>
> > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > *Github: https://github.com/rmannibucau*
> >
> >
> >
> > 2013/2/11 Kristian Rosenvold
<kristian.rosenv...@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 <rmannibu...@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>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/2/8 Anders Hammar <and...@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.rosenv...@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 has been
filed
> and
> > > > > "fixed"
> > > > > > which will revert the behaviour back to "slow" for both war
and
> > > > assembly,
> > > > > > So what do you think ?
> > > > > >
> > > > > >
> > > > > > Kristian
> > > > > >
> > > > >
> > > >
> > >
> >
>
