+1 for a) even if b) does promise reproducible builds. Having all files stick to a given (default) encoding will mean a nightmare to all platforms where such encoding is not the system one when it comes to modifying or editing files.
Thus, in addition to a) (allowing files to stick to whatever encoding the local system lives in) we should deprecate any file operation that fails stating an explicit encoding and this way encourage users to explicitly state the encoding in use. Actually, I'm in favour of c) a) + discourage any use of files that do not state encoding explicitly (probably pom 4.0.1 could require stating an explicit encoding?) This way backward compatibility is achieved for "old" projects. Any new ones may use any encoding appropriate for local use (and this may change form version to version). But on the other hand correct interpretation is ensured as there will be no doubt what encoding to use for interpreting files. (Probably a <encoding> element at pom level will suffice for the start) Rainer Benjamin Bentmann schrieb: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
