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
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]
