I created http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-2216/
with javadoc and jxr plugins branches to test the change, and sample use
case.
no reaction: I suppose this is lazy consensus :)
I'll start to merge to plugins trunks tomorrow
regards
Hervé
Al the work is being put on a branch right? That was where I saw the discussion
with Jason going.
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2008 10:06 AM
To: Maven Developers List
Subject: Re: [VOTE] POM Element for Source File Encoding
/MAVENUSER/POM+Element+for+Source+File+Encoding
any objection?
Hervé
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 12, 2008 10:06 AM
To: Maven Developers List
Subject: Re: [VOTE] POM Element for Source File Encoding
I created http
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
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
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
Taking this together, one might argue to have UTF-8 the default, not
ISO-8859-1.
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,
As for today, I tried to consider consistency with existing behavior.
The
Maven Site Plugin was already using Latin-1 as the default value for
inputEncoding and outputEncoding and so I proposed this for other
plugins,
too. Indeed, one of the patches (MJAVADOC-165) was just released such
that
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.
All sounds fine. Just wanted you to think about the bigger picture in
mind.
Please do the work on a branch and go through the rigor of Brian's
example and make sure it works before you merge it into something we
would release to users. This is not an insignificant change.
On 9-Apr-08, at
Make sure you consider the case where you have people developing the same
code base all over the world, and the possible reasoning of falling back
to platform default encoding. Consider the team spread across the US,
Russia, and China and what do they do normally?
This international spread
I see your point. Worth another vote? Or should this switch be postponed
to 2.1, trading consistency in minor version upgrades for a longer time
for these Latin1 defaults to be established?
[...]
So while I agree that a change in default either now or in the future is
ugly, it is not taboo, and I
On Wed, Apr 9, 2008 at 7:36 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
Make sure you consider the case where you have people developing the same
code base all over the world, and the possible reasoning of falling back to
platform default encoding. Consider the team spread across the
Le mercredi 09 avril 2008, Benjamin Bentmann a écrit :
I see your point. Worth another vote? Or should this switch be postponed
to 2.1, trading consistency in minor version upgrades for a longer time
for these Latin1 defaults to be established?
[...]
So while I agree that a change in
Le mercredi 09 avril 2008, Jason van Zyl a écrit :
All sounds fine. Just wanted you to think about the bigger picture in
mind.
Please do the work on a branch and go through the rigor of Brian's
example and make sure it works before you merge it into something we
would release to users. This
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
Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
I'm not really sure what you meant to say. JChardet is a library that
performs a best *guess* on file encoding by peeking at a byte stream. We
don't want to base our
Hervé Boutemy wrote:
this one is more tricky, even if the change in pom.xml is a simple
addition of
an element... Don't really know how to handle this without breaking things
for Maven 2.0 when an artifact with this addition is deployed to a
repository.
Handling POM additions is a more general
On 8-Apr-08, at 1:09 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
I'm not really sure what you meant to say. JChardet is a library
that performs a best *guess* on file encoding by
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from having to know
or worry about it then yes I would use it.
Could you elaborate this a little more. Say we start easy and have a build
with just about 100 Java source files. Do you suggest to peek at each of
them
+1 on Benjamin's objections to detection.
It will slow down the build (possibly significantly) while providing
little added value.
Milos
On Tue, Apr 8, 2008 at 8:27 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from
On 8-Apr-08, at 11:27 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
If it's right most of the time, and it saves the user from having
to know
or worry about it then yes I would use it.
Could you elaborate this a little more. Say we start easy and have a
build
with just about 100
On 8-Apr-08, at 11:11 AM, Milos Kleint wrote:
+1 on Benjamin's objections to detection.
It will slow down the build (possibly significantly) while providing
little added value.
Possibly, but you're guessing.
Obviously checking the encoding on every file would be unwise. Trying
to detect
+1 for the original proposal, if a newcomer like me is allowed to vote.
The concept with the property, which can be set with the properties
until the model is updated, and which can be the default expression for
affected plugins, is simply elegant.
Jason van Zyl wrote:
It would be reasonable
Le mardi 08 avril 2008, Paul Benedict a écrit :
In Commons Validator, we updated the DTD even in point releases. I don't
see the harm in doing the same here. After all, if the POM is 4.0.0, why
not create a 4.0.1? It sounds like Maven 2 will have a 4.1 version.
Paul
because if you use 4.0.1
Le mardi 08 avril 2008, Martin von Gagern a écrit :
+1 for the original proposal, if a newcomer like me is allowed to vote.
The concept with the property, which can be set with the properties
until the model is updated, and which can be the default expression for
affected plugins, is simply
Martin von Gagern wrote:
if a newcomer like me is allowed to vote.
The more people participate in a discussion, the more likely is the result
to match public consensus rather than individual's preferences.
Suppose you have a huge source tree, mostly english ASCII, but somewhere
in there
Jason van Zyl wrote:
Possibly, but you're guessing.
Guessing about how much it will be slower, yes, guessing that it will be
slower, no. Additional work, additional time. Wouldn't you agree? Then the
question becomes, is it worth to take this overhead, or how much benefit do
you expect from
Herve,
Just a proposal: Maven could loosen its parsing rules when it detects
versions greater than it is configured to accept. This can't be without
limits, of course, perhaps in the range of a single point release: 4.0 =
4.0.x 4.1. But perhaps within the 4.0.x series, it would accept undeclared
Jason van Zyl wrote:
What happens when the encoding is different then what is stated? Same
problem really, in how to deal with the actual versus declared.
If the declared encoding does not match the actual one, I simply call this
an user error. Either he explicitly set the wrong value or
IMHO, the best hint for a user choose his encoding when the default
ISO-8859-1
isn't a good valuie for him, is displaying platform encoding (in mvn -v
output for example): it's easy, reliable, and corresponds to the value he
would have got before the change
+1, just created MNG-3509 for this.
On 8-Apr-08, at 4:09 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
What happens when the encoding is different then what is stated?
Same problem really, in how to deal with the actual versus declared.
If the declared encoding does not match the actual one, I simply
call this an user
Please clarify the proposal. When you say source files, you mean things
like Java files not POM files?
Yes, source file is meant to refer to a plain text file that does not have
an encoding declaration or similar like XML. XML is fine, it's ugly to parse
but provides the user with means to
I'd like to know if this could also be achieved via toolchains.
As Hervé already tried to explain, these two proposals have not too much in
common. To my understanding, the toolchain proposal aims at providing a
facade on a user's development kit (native tools, boot class path, etc.)
such that
My only concern is that the encoding kind of assumes one kind of source
file. I am never in a position to have multiple encodings on my projects,
but I suppose if you're compiling many differrent types of sources, people
would want to tie the source to the extension type.
Paul
On Mon, Apr 7,
+1
On Sat, Apr 5, 2008 at 2:20 PM, Hervé BOUTEMY [EMAIL PROTECTED] wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by each
and every plugin,
2008/4/5, Hervé BOUTEMY [EMAIL PROTECTED]:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by each
and every plugin,
2. a default value set to
Le lundi 07 avril 2008, Asgeir S. Nilsen a écrit :
2008/4/5, Hervé BOUTEMY [EMAIL PROTECTED]:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by
Le dimanche 06 avril 2008, Jason van Zyl a écrit :
I specifically meant the core changes, but I would still recommending
what Milos did which was to create branches for a few of the affected
plugins to try it all together.
ok, I created
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
On 7-Apr-08, at 2:31 PM, Hervé BOUTEMY wrote:
Le dimanche 06 avril 2008, Jason van Zyl a écrit :
I specifically meant the core changes, but I would still recommending
what Milos did which was
On 7-Apr-08, at 3:58 PM, Jason van Zyl wrote:
Would being able to detect the encoding help with making this less
complicated. Something JChardet?
Sorry, something like JCharet:
http://jchardet.sourceforge.net/
On 7-Apr-08, at 2:31 PM, Hervé BOUTEMY wrote:
Le dimanche 06 avril 2008,
In Commons Validator, we updated the DTD even in point releases. I don't see
the harm in doing the same here. After all, if the POM is 4.0.0, why not
create a 4.0.1? It sounds like Maven 2 will have a 4.1 version.
Paul
On Mon, Apr 7, 2008 at 6:03 PM, Jason van Zyl [EMAIL PROTECTED] wrote:
On
+1
Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by each
and every plugin,
2. a default value set to ISO-8859-1 (instead of
Please clarify the proposal. When you say source files, you mean things
like Java files not POM files?
Paul
On Sun, Apr 6, 2008 at 2:56 PM, Dennis Lundberg [EMAIL PROTECTED] wrote:
+1
Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
+1 .. I'd like to know if this could also be achieved via toolchains.
Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by each
and every plugin,
2. a default value set to ISO-8859-1 (instead of platform encoding) to have
+1
Is there any overlap with the tool chain proposal ?
Nico
2008/4/5, Hervé BOUTEMY [EMAIL PROTECTED]:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be
+1
Benjamin
Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list about Maven and encoding 2 weeks ago,
Benjamin and I worked on a proposal to have:
1. a central point of configuration of sources encoding, to be used by
each
and every plugin,
2. a default value set to ISO-8859-1
On Sat, Apr 5, 2008 at 7:20 PM, Hervé BOUTEMY [EMAIL PROTECTED] wrote:
[...]
The full proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Non-binding +1
Regards,
Tomek
-
To
You don't need a 72 hour vote, I would try it in a branch first and
then get people to look at it.
It's a good idea, just don't do it on trunk directly so that we have
the before and after to compare.
On 5-Apr-08, at 10:20 AM, Hervé BOUTEMY wrote:
Hi,
Since the discussion on the list
Le samedi 05 avril 2008, nicolas de loof a écrit :
+1
Is there any overlap with the tool chain proposal ?
as I understand the tool chain proposal, no overlap at all
the tool chain is here to let a central place to configure tools on every
developer environment (like where is javac 1.5)
source
Jason van Zyl wrote:
You don't need a 72 hour vote, I would try it in a branch first and then
get people to look at it.
Just wondering: If I would fill in JIRAs for each affected plugin to request
a) adding an encoding parameter if not already existent
b) making this parameter default to
On 5-Apr-08, at 3:13 PM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
You don't need a 72 hour vote, I would try it in a branch first
and then
get people to look at it.
Just wondering: If I would fill in JIRAs for each affected plugin to
request
a) adding an encoding parameter if not
53 matches
Mail list logo
