> 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:;>> > > > > > 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:;>> > > > > > > > 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:;>> > > > > > > > > > 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:;>> 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 > > > > > > > > > > > > > > > > > > > > >
