Jason van Zyl wrote:
Possibly, but you're guessing.
Guessing about how much it will be slower, yes, guessing that it will be
slower, no. Additional work, additional time. Wouldn't you agree? Then the
question becomes, is it worth to take this overhead, or how much benefit do
you expect from the encoding guess over the simple default value.
Obviously checking the encoding on every file would be unwise.
As Martin nicely illustrated, you would exactly have to do this. Otherwise,
you could simply shortcut the detection to ASCII because that's what you see
most of the time. The characters that require the proper encoding are in the
minority. My passion for this proposal is not about "works most of the
time", I would like to see "works always".
Trying to detect where it's not provided (mistakes)
We proposed to set a default value in the super POM such that the encoding
will always be specified. To handle Maven 2.0.9-, we further proposed that
each plugin consistently falls back to this agreed default value in case it
doesn't get a value from the POM. Is there a case I am missing?
or can't be provided (not supported as an option in the model) you're
going to have to do something. So what are you going to do in those cases?
I am not sure what you mean when referring to "model". Are you referring to
a plugin that is currently not aware of the encoding issue, i.e. simply uses
the JVM's default value and does not provide a configuration parameter to
the user? For this case, we should simply fix this plugin and release a new
version of it to deliver "consistently high quality software".
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
