Paul Benedict wrote:
My only concern is that the encoding kind of assumes one kind of source
file.
We are well aware that different kind of text files may use different
encodings. A simple example is using UTF-8 for Java source files and Latin-1
for properties files.
However, the primary goal of the proposal is to replace the default encoding
defined by the JVM (platform-dependent) with a value defined by the POM
(platform-independent).
Hence, we started off with a single default value. The emphasis lies on
*default*, i.e. the proposed POM property/element is not intended as the
final means to configure the employed file encoding throughout the entire
project. It is just a value plugins can use to initialize their
configuration in case the user did not explicitly specify an encoding.
I am never in a position to have multiple encodings on my projects
And I would argue that not too few people follow the same approach.
Otherwise I can hardly understand why users did not already complain about
those plugins don't provide an encoding parameter at all yet. Besides, not
every IDE allows users to configure different file encodings in a single
project so this seems really the major use case.
but I suppose if you're compiling many differrent types of sources, people
would want to tie the source to the extension type.
A file extension is just one method to distinguish files, another one is
context of use. I believe that having the possibility to configure file
encoding on a per plugin basis is good enough to capture different types of
files.
If really someday the need to setup encodings per file extension arises, we
can think more closely about that. But even then, I wouldn't like to write
something like this in my POM to lock down the encoding for every file
extension that might hang around in the project:
<fileEncodings>
<fileEncoding>
<extensions>txt,java,groovy,aj,bsh,apt,...</extensions>
<name>UTF-8</name>
<fileEncoding>
</fileEncodings>
I would want to have a single default value to catch the major case and this
default value should in no case depend on my JVM. So I'm back on
${project.build.sourceEncoding}.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
