Benjamin Bentmann schrieb: > Rainer Pruy wrote: > >> Putting up a default behaviour that deviates from current default, >> will not bring consistent builds for those projects. > > I would like to argue the opposite: If we consider a project whose POM > does not explicitly specify file encodings for the plugins in use, each > developer will implicitly use his platform default encoding during the > build. Further assume that the platform default encoding among the > project team differs (for whatever reason). This potentially causes the > build output for developer A and developer B to differ although they are > - building from the same POM > - using the same Maven version > - using the same plugin versions
Yes I see your argument, nevertheless there are large areas where a "breaking" build does not imply receiving some kind of error message. I'd assume there are numerous cases where "breaking" just implies strange results somewhere in an application. This will not get improved on changing default encoding, it will just happen to "break" in a different way. So why not leave the bad situation as is and avoiding making it worse by adding the chance that some build will exhibit breaks while still in "uncritical" environments. (Causing some improvents for the price of being "unpolite" as you did put it below) If already being unpolite why not in a way that will cause major improvement on the situation by forcing users to stating encoding in any case and keeping current problems on current project settings. Fixing some "by default" while breaking others (causing them to get fixed). Same effect if *any* build is flagging bad usage of encoding (aka missing encoding declarations) and building up some pressure on people providing projects publicly. No changes for "old" ones -- consistent improvement for anything else.... > > In contrast, if the unspecified file encoding defaulted to a > platform-independent value defined by a Maven convention, the build will > a) either work for both developers or > b) work for none of them > in both cases, they observe the same build output. > > I mean, the major aspect of the Maven default encoding being Latin-1 > instead of UTF-8 or whatever people's platfrom encoding is, is that this > value is platform-independent and as such applies to the entire team > (unless their override it). > >> Most likely the files are not compatible with the new implied default. > > Yes, but you would simply need to fix your POM and are back on the road. > >> Thus flagging encoding problems will improve awareness and will surely >> contribute more to consistent builds that "changing the rules" on the >> game... > > If we change the rules such that the build of those people, that are > currently unaware of the encoding issue and simply assume their platform > encoding, can break, that's some kind (though not fully reliable) of > flagging encoding problems, IMHO. Yes, yes, that might not be the most > polite way of promoting things, but sometimes I feel a little emphasis > is OK. > > > 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]
