Hi Benjamin, Benjamin Bentmann schrieb: > Manos Batsis wrote: > >> 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. > > I can't follow your arguments here. Proper text editors allow you to > select the file encoding you save your files in, so the system default > encoding should not matter. >
This might be true for an all java world, nevertheless, in case the maven default deviates from your platform one, how does an editor know where to get the proper encoding for a given file? (It would be quite difficult to enrich *any* editor around with some logic to default to "maven" encoding in case there is a pom along the path. so, it might work for IDEs where all aspects are tightly integrated..) (Personally, I would not like to be forced to dump good ol' vi (;-)) >> we should deprecate any file operation that fails stating an explicit >> encoding and this way encourage users to explicitly state the encoding >> in use. > > I'm not sure what you mean with "file operation". here: reading from and writing to files > > We have feature requests out for PMD and Checkstyle to detect usage of > problematic IO APIs like java.io.FileReader and I know that already some > work on these has been started. > > As for the Maven plugins themselves and their file handling: We don't > need to deprecate things here. Every plugin that reads/writes plain text > files should offer an encoding parameter for the user to configure the > correct file encoding. Work on extending unconfigurable plugins with > such a parameter is in progress/scheduled. > Sorry for not being precise enough. I did not mean "deprecation" in the specific meaning of interface elements. It was more towards arranging for any "file operation" (see above) without explicit stated encoding to fail (ok, this might be to tough, but a warning would be minimum here) >> c) a) + discourage any use of files that do not state encoding >> explicitly > > I take this as a vote for a) with the intention to output a warning in > case the encoding was not specified. Please correct me if I > misunderstood you. > You are right: As I stated at the very top of my message: +1 for a) This poll is about "default" without any explicit setting. a) is the least disturbing one for users and teams within a homogeneous environment. As inhomogeneous teams already face problems and sure will come to using encoding config quickly, a) is least disturbing. Rainer > > Benjamin > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Rainer Pruy Geschäftsführer Acrys Consult GmbH & Co. KG Untermainkai 29-30, D-60329 Frankfurt Tel: +49-69-244506-0 - Fax: +49-69-244506-50 Web: http://www.acrys.com - Email: [EMAIL PROTECTED] Handelsregister: Frankfurt am Main, HRA 31151 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
