definitely option [a] respecting platform default encoding is the convention with the highest weight, and option [b] simply breaks this convention by not respecting platform default encoding.
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set, one will be very confused in case of option [b], when maven uses another encoding such as utf-8 this is just an example and may not be the actual case, surely I know utf-8 is a good thing furthermore, if a lot of applications behave like option [b], but unfortunately they use inconsistent default encoding, then you know what a hell is. and always respecting platform default encoding is the correct way to make an application encoding-transparent so the application developer don't need to worry about converting back-n-forth between several encodings/charsets, given the context of a standalone system as a sandbox. IMO, e.g., networking related applications, have to deal with encoding, this is by nature, since network is used to connect people from different places. If the developer of a multi-encoding application don't understand what encoding is, he/she should learn it, you just can not assume the multi-encoding application as a single-encoding application an encoding, to a text parser application, is like the language spoked to the audience, you just can not assume the speaker of any lecture always uses English. It's easy for people to know that there are so many languages spoked in the world, it's just one more step further to understand that "different" text parsers also read in different encodings On 4/29/08, Benjamin Bentmann <[EMAIL PROTECTED]> wrote: > > Dear community, > > the Maven team is currently discussing a proposal about the future > handling > of source file encoding by the various plugins, please see our wiki > article > [0] for all details. > > A controversial aspect of this proposal is which file encoding should be > assumed in case the user did not specify this in the POM. This poll should > help us to come to a well-founded decision. > > These are the two possible directions to go: > > a) Use the current platform encoding, aka the system property > "file.encoding". > > b) Use a static/fixed value that is defined by convention, i.e. is not > platform-dependent. > > Approach a) matches the current behavior of most plugins and is as such > backwards-compatible. Approach b) on the other hand can potentially break > builds when users update to a newer version of an affected plugin if: > - the build relies on an encoding other than ASCII/Latin-1 and > - this encoding is not explicitly stated in the plugin configuration > > The reason why b) was suggested is its positive effect on build > reproducibility: Unlike approach a), a build will out-of-the-box deliver > the > same output for all team members regardless of their OS or locale. It is > now > to balance if this improvement is worth the potential breaks as > illustrated > above. > > So, please let us know: > > [a] Use platform default encoding, keep backward-compat > [b] Use fixed default encoding, be platform-independent > > Regards, > > > Benjamin Bentmann > > > [0] > > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
