> 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.conno...@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.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<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 >>> > > > > <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<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-unsubscr...@maven.apache.org> > For additional commands, e-mail: dev-h...@maven.apache.org > >
