Hi, On 4/30/08, Benjamin Bentmann <[EMAIL PROTECTED]> wrote: > > I agree, having users explicitly state the encoding in their POMs is the > best we can have, the same applies to locking down plugin versions by the > way. No guessing, no implicit default values, just full control, let's call > it "heaven" ;-) > > But how to get their? The threat I see with continuing to use the platform > default encoding is that people will be left unaware of the encoding issue > because platform default encoding works just nicely most of time.
For projects involving developers from different country (i.e. the developers use different default encodings from one to another), it's a must for everyone in the team / project to understand that his/her default encoding is not the "default" for others, e.g. I'm from China, I've created a Maven project, using the my default encoding GBK, and then shared it with you, Benjamin, then how would you collaborate with me? surely you cannot assume the encoding to be iso-8859-xx (your system default, excuse me if I'm wrong) Then there are two solutions IMO: 1). we set GBK as source file encoding in pom.xml 2). we don't change pom.xml, but we both use an imaginary-maven-fork which treats every file as encoded in GBK, this does not be platform-dependent. as option b) will you agree with solution 2)? even if there're 99 developers from China while only one of you from Germany :P so, I insist option a), and if it's problematic without explicit encoding, it means an explicit encoding is required in the POM. and I also insist that it's important for developers to understand the root cause of the inconsistent build result generated by developers from different country / region. such developers should understand Unicode, and different encodings, and how the platform default encoding affects the build result. Thanks Roger Or just a warning for not to expect "whole world is just using your > > preferred encoding"? > > > Yes, a nice warning is surely due if a) wins. > Benjamin > >
