+1 for b) - reproducibility is more important that the bother to have to
define the encoding explicitly.
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]
