"Select is not broken" Kristian
2013/2/11 Anders Hammar <and...@hammar.net> > "It's just a small change. No need to test that..." > > Famous last words! :-) > > /Anders > > > On Mon, Feb 11, 2013 at 9:26 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > 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>* > > > > > *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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
