Benjamin Bentmann wrote:
In general, I completely agree with your preference to Unicode and
fail-fast
behavior. If I had been involved when the Maven story started, I would have
proposed UTF-8 as the default value, no doubt.
As for today, I tried to consider consistency with existing behavior.
Benjamin Bentmann wrote:
With regard to user errors, my general
suggestion is to fail the build. This unforgiving attitude should not be
that unfamilar to users: It has been chosen for a popular format like
XML which is also employed by Maven for a few files.
The problems depend on the encodi
Paul Benedict wrote:
Just a proposal: Maven could loosen its parsing rules when it detects
versions greater than it is configured to accept.
Forward compatibility would be nice.
For anyone seriously interested in interoperability , I suggest a look
at http://www.w3.org/2005/05/xsd-versioning-
Benjamin Bentmann wrote:
You could of course write an encoding detection plugin which could
examine the code and set the required property accordingly.
Personally, I don't see the use case for that. If there are really users
out there that don't know what file encoding they are using when writ
guess the danger of inconsistent
input handling, as different plugins might be configured to read it
using different charsets, is exactly the kind of inconsistency to be
addressed by this proposal, so I'd expect more consistency after it has
been implemented, not less.
Greet
viour?
Let me know what you think of all this, how you would suggest I proceed,
and what other resources might be useful. I don't have too much time to
spare for this issue, but I believe it important enough to do some work
for it from time to time, and when I do so, I might as well do s
James William Dumay wrote:
Rahul,
Something like this library might help you in your quest...
http://sourceforge.net/projects/javacurses/
James
CHARVA might be useful as well:
http://www.pitman.co.za/projects/charva/
It seems both require a native DLL in order to work properly. This makes
s
