There is one feature in this patch I don't like: you hardcoded a default
encoding to ISO-8859-1 instead of no default value (which means platform
encoding).
Indeed, I also suggested using a fixed default value for other plugins:
- MCOMPILER-63
- MJAVADOC-165
- MRESOURCES-57
I simply chose Latin-1 here to be consistent with the Site Plugin whose
inputEncoding/outputEncoding likewise defaults to Latin-1 for quite some
time.
even if a developer wanted to configure platform encoding, he could not!
Something like
<encoding>${file.encoding}</encoding>
should still do, wouldn't it?
Platform encoding is here to give most developers freedom to ignore
encoding notions. And most of the time it works well.
Every native tool use platform encoding by default, so do javac, javadoc,
ant,...
You basically describe the status quo for the encoding handling. Now I
believe that some improvements simply require to break with existing
standards to get away from questionable decisions made in the past. For
instance, Maven 2.0.8 and Surefire 2.3.1 introduced deterministic/correct
class path ordering. This caused some people's builds to fail but
nevertheless I believe this change was the only way to go.
Considering the following circumstances
a) Java has an international audience and
b) developer communities are joined from different countries
I believe that to "ignore encoding notions" is an anti-pattern that should
be banned, not supported. Also, I guess that it's partly this ignorance that
caused and still causes all the pain with proper encoding support in Maven:
If developers would have been required to explicitly specify file encodings
for tools like javac or classes like FileWriter/FileReader, I believe that
would have made them sensible to the topic and could have prevented some of
the design/implementation flaws we see right now.
Personally, I'm a fan of these Maven philosophies:
- ensure builds are reproducible
- prefer convention over configuration
If I apply those to the encoding issue as well (as a matter of consistency),
the conclusion is to have Maven provide a fixed default value for the
encoding.
Having a default encoding is not consistent, and people not using
ISO-8859-1 as their platform encoding won't understand the failure (or
understand this is a complicated encoding problem caused by a bad tool).
Also note, that Maven already chose to be inconsistent with native tools
regarding compiler source/target settings. The native javac defaults these
options according to its own JVM while Maven uses fixed default values.
Those defaults caused compilation failures for my builds and made me spend
some minutes to fix the POM. However, I wouldn't blaim Maven here for being
inconsistent, I'm happy it taught me to get my build platform-independent.
To help developers discover that relying on platform encoding is not a
good choice, I think there are better ways than stopping the "magic" of
it:
I feel this is similar to the auto-update "feature" for Maven plugins: I'm
not sure but wasn't the consensus about this to disable auto-update by
requiring the existence of <version> elements for plugins in the POM für
Maven 2.1? This would also mean a stop of "magic" though in a
smoother/expected way since the POM version would change and as such has all
right to define different validation semantics.
- I just changed resources plugin with MRESOURCES-62 to be more explicit:
> [INFO] [resources:resources]
> [INFO] Using platform encoding (UTF-16 actually) to copy filtered
> resources.
Side note: I would prefer to output the last log message on level "WARNING".
An INFO message is ordinary output noise, nobody will care about that,
leaving the POM as bad as is.
- perhaps Maven itself should show the good habits: define a property in
the parent pom and take care of properly declaring encoding for plugins
I agree here, Maven should definitively have a central property in the POM
to control encoding for an entire build. See also MNG-2216.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
