You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2013/02/07 21:58:06 UTC
Fast or exact ?
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
Re: Fast or exact ?
Posted by Olivier Lamy <ol...@apache.org>.
+1 for fast per default
2013/2/11 Kristian Rosenvold <kr...@gmail.com>:
> 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 <rm...@gmail.com>
>
>> 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 <an...@hammar.net>
>>
>> > 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> 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
>> > >
>> >
>>
--
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fast or exact ?
Posted by Anders Hammar <an...@hammar.net>.
> 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 <st...@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<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Fast or exact ?
Posted by Robert Scholte <rf...@apache.org>.
Please, don't abuse the release-profile for these kind of things.
Use it for things which are only *required* during a release, like signing.
During any build you should have the choice for a "fast" or "exact"
archive.
So if you want to make an example, use a separate profile.
thanks,
Robert
Op Mon, 11 Feb 2013 21:26:35 +0100 schreef Stephen Connolly
<st...@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>*
>> > > *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.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>*
>> > > > > *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 <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 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
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fast or exact ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
"Select is not broken"
Kristian
2013/2/11 Anders Hammar <an...@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.connolly@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.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>*
> > > > > > > *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 <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 has been
> > filed
> > > > and
> > > > > > > > "fixed"
> > > > > > > > > which will revert the behaviour back to "slow" for both war
> > and
> > > > > > > assembly,
> > > > > > > > > So what do you think ?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Kristian
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Anders Hammar <an...@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.connolly@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.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>*
> > > > > > *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 <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 has been
> filed
> > > and
> > > > > > > "fixed"
> > > > > > > > which will revert the behaviour back to "slow" for both war
> and
> > > > > > assembly,
> > > > > > > > So what do you think ?
> > > > > > > >
> > > > > > > >
> > > > > > > > Kristian
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Stephen Connolly <st...@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>*
> > > *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.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>*
> > > > > *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 <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 has been filed
> > and
> > > > > > "fixed"
> > > > > > > which will revert the behaviour back to "slow" for both war and
> > > > > assembly,
> > > > > > > So what do you think ?
> > > > > > >
> > > > > > >
> > > > > > > Kristian
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Anders Hammar <an...@hammar.net>.
> 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.rosenvold@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 <rmannibucau@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 <anders@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.rosenvold@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
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Stephen Connolly <st...@gmail.com>.
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
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.rosenvold@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 <rmannibucau@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 <anders@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.rosenvold@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
> > > > >
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <kr...@gmail.com>
> 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 <rm...@gmail.com>
>
> > 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 <an...@hammar.net>
> >
> > > 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> 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
> > > >
> > >
> >
>
Re: Fast or exact ?
Posted by Kristian Rosenvold <kr...@gmail.com>.
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 <rm...@gmail.com>
> 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 <an...@hammar.net>
>
> > 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> 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
> > >
> >
>
Re: Fast or exact ?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <an...@hammar.net>
> 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> 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
> >
>
Re: Fast or exact ?
Posted by Hervé BOUTEMY <he...@free.fr>.
+1
good result without config is the default
people wanting to tweak will learn how to do it, and how to get back to exact
when they release, which requires some organization
Regards,
Hervé
Le vendredi 8 février 2013 08:43:25 Anders Hammar a écrit :
> 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> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Fast or exact ?
Posted by Anders Hammar <an...@hammar.net>.
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> 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
>
Re: Fast or exact ?
Posted by Andreas Gudian <an...@gmail.com>.
Ok, just read it - it /is/ an option. That's all I care about ;).
Am Donnerstag, 7. Februar 2013 schrieb Andreas Gudian :
> I think I'd like to have the choice, i.e. I'd like an option for that.
>
>
> Am Donnerstag, 7. Februar 2013 schrieb Kristian Rosenvold :
>
>> 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
>>
>
Re: Fast or exact ?
Posted by Andreas Gudian <an...@gmail.com>.
I think I'd like to have the choice, i.e. I'd like an option for that.
Am Donnerstag, 7. Februar 2013 schrieb Kristian Rosenvold :
> 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
>