Hi all, +1 [a]
with a few considerations (please, correct me if i'm wrong): - backward compatibility is not a must, but a cost if not assured; runtime charset errors (other than build-breaking ones) may be hard to detect - most companies have uniform OS platforms; teams with non-uniform developing environments have already faced this problem: editing a file with a different encoding requires some thought.. far before building - most editors allow you select a proper charset, but they (usually) automatically detect the default ("file.encoding"); it'd be not comfortable changing every time the charset to a different one only because maven said "this is the standard"; i.e., i wouldn't exchange platform-dependence with implicit charset-dependence (potential drawbacks on all other kinds of editor - java/sql/xml/properties/..) - big trans-national companies (should!) have centralized and well-configured building-machine to be asked for deliverables; those deliverables are surely reproducible and should be deployed to official/uniform testing and production environments regards, Paolo Benjamin Bentmann 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] > > > -- View this message in context: http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16963039.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]