Benjamin Bentmann wrote:
A controversial aspect of this proposal is which file encoding should be
assumed in case the user did not specify this in the POM. This poll should
help us to come to a well-founded decision.
These are the two possible directions to go:
a) Use the current platform
Benjamin Bentmann wrote:
Manos Batsis wrote:
I hate this! Someone finally agrees with me but in a misquoted email; I
never wrote that :-)
As I said, that was my fault of getting the reply header wrong, I apologize
for this confusion. I didn't want to upset you Manos.
No prob, sorry if i
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki article
[0] for all details.
A controversial aspect of this proposal is which file encoding should be
assumed in case the user did not
+1 for the option b.
We had our share of builds behaving differently from OS to OS and
from region to region. :(
cheers,
sherali
29/04/2008, в 21:23, Benjamin Bentmann писал(а):
Dear community,
the Maven team is currently discussing a proposal about the future
handling
of source file
Definitely b)
Reproducable builds are an absolute requirement for a build tool.
Benjamin Bentmann wrote:
Dear community,
the Maven team is currently discussing a proposal about the
future handling
of source file encoding by the various plugins, please see
our wiki article
[0] for all
definitely a)
I can't help myself I'm a backward compatibility guy.
Just a note, both solution allow one to have a reproducible builds if
one cares. Benjamin and Herve (and others) have done a great job on
making sure that when you set the encoding for the project it gets
applied consistently
Benjamin Bentmann wrote:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
Hi
I vote for b). The different file encodings on different environments
are a mess.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
+1
Starting a new maven project and not being aware of this thread /
encoding problem I (speaking as maven user) for sure will not set an
encoding and rely on the 'default' encoding. Doing so may
+1 for [b]
Many novide developper don't even know what character encoding is. I had to
explain many time why the same application, compiled under a Unix server did
not generate the same result for some txt files with french characters.
Backward compatibility is nice but this doesn't mean user
I definitely vote for A but I see those who vote for B as valid as well. A
is basically today's choice since the default today is the platform's
encoding. If people want to override the default and forget about it, it
tells me it should belong in a corporate POM, which implies A again.
Paul
On
Benjamin Bentmann wrote:
e the two possible directions to go:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
My vote is certainly b. However and IMHO, plugins that
+1 for a)
even if b) does promise reproducible builds. Having all files stick to a given
(default) encoding will mean a nightmare to all
platforms where such encoding is not the system one when it comes to modifying
or editing files.
Thus, in addition to a) (allowing files to stick to whatever
+1 for b) - reproducibility is more important that the bother to have to
define the encoding explicitly.
Benjamin Bentmann wrote:
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki
+1 for b. And let it be UTF-8.
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Dear community,
the Maven team is currently discussing a proposal about the future handling
of source file encoding by the various plugins, please see our wiki article
[0] for all details.
A
On Tue, Apr 29, 2008 at 1:23 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
These are the two possible directions to go:
a) Use the current platform encoding, aka the system property
file.encoding.
b) Use a static/fixed value that is defined by convention, i.e. is not
+1 for b)
Reproductible builds is _the_ shit.
About backward compatibility, I second Nicolas about reading releases notes,
upgrade guides etc...
Le Tuesday 29 April 2008 13:23:44 Benjamin Bentmann, vous avez écrit :
Dear community,
the Maven team is currently discussing a proposal about
, April 29, 2008 7:24 AM
To: users@maven.apache.org
Subject: [POLL] Default Value for File Encoding
Dear community,
the Maven team is currently discussing a proposal about the future
handling
of source file encoding by the various plugins, please see our wiki
article
[0] for all details
-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16960887.html
Sent from the Maven - Users mailing list archive at Nabble.com
+1 to c.
On Tue, Apr 29, 2008 at 8:51 AM, Jochen Wiedmann [EMAIL PROTECTED]
wrote:
On Tue, Apr 29, 2008 at 1:23 PM, Benjamin Bentmann
[EMAIL PROTECTED] wrote:
---clip---
I'd opt for
c) Use a configurable value, by default the current platform encoding.
Should be
* Upwards
Milos Klient wrote:
Just a note, both solution allow one to have a reproducible builds if
one cares.
Absolutely. Just to further clarify: This poll is not about reproducibility
or not. Setting the encoding explicitly in the POM will always give you a
reproducible build, no matter where this
Marat Radchenko wrote:
And let it be UTF-8.
Well, that's another story ;-)
The problem is we have already two plugins out (Site and Javadoc) that
employ Latin-1 as the default value. Either we have them break to use UTF-8,
too, or leave those two as exceptions to the rest of the plugins. Both
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a nightmare
to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your arguments here. Proper text editors allow you to select
the file
Manos Batsis wrote:
This should have been Rainer Pruy, I'm sorry.
Benjamin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Jochen Wiedmann wrote:
I'd opt for
c) Use a configurable value, by default the current platform encoding.
To my understanding, that's nothing more than variant a). Of course, we are
talking about a configurable value. Locking down plugins to any kind of
encoding without having a chance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/-POLL--Default-Value-for-File-Encoding-tp16958386s177p16963039.html
Sent from
Brian E. Fox wrote:
Can you outline in what cases and in what ways this change could break
existing builds
Surely. About the cases that might suffer from the change: We propose to use
Latin-1 as the default encoding in case the user did not specify it. So
first up, everybody who already
definitely option [a]
respecting platform default encoding is the convention with the highest
weight,
and option [b] simply breaks this convention by not respecting platform
default encoding.
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b],
Paolo Compieta wrote:
- most companies have uniform OS platforms
I am used to scenarios where people work on Unix/Win terminals or their
Unix/Mac/Win notebooks on their own discretion, creating quite some
heterogenous development culture. Might be one reason why I quickly had
locked down all
Hey,
No offense, I bet you're an American and never read the joke which involves
trilingual, bilingual and American
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms
My vote is [b]. Consistent builds are the very foundation upon which we operate.
Wayne
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Sherali,
On 4/29/08, Sherali Karimov [EMAIL PROTECTED] wrote:
+1 for the option b.
We had our share of builds behaving differently from OS to OS and from
region to region. :(
Excuse me, but I think this is your fault.
This is exactly the case where you should use explicit encoding
Like
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers has LC_ALL
set to a different value, won't he be confused why
Hi Benjamin,
Benjamin Bentmann schrieb:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your arguments here. Proper text
Roger Ye wrote:
No offense, I bet you're an American and never read the joke which
involves trilingual, bilingual and American
I am from Germany, not sure how close that counts to being American ;-)
Anyway, you're right, I can't remember the joke you referred to.
please consider what if in
Benjamin Bentmann schrieb:
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers has
LC_ALL set to a different
Wayne Fay schrieb:
My vote is [b]. Consistent builds are the very foundation upon which we
operate.
(Sorry Wayne it is not personal, I just came across that thought while reading
your post.)
Putting up a default behaviour that deviates from current default, will not
bring consistent
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Roger Ye wrote:
e.g., in Linux, if LC_ALL=en_US.UTF-16 has been set,
one will be very confused in case of option [b], when maven uses another
encoding such as utf-8
Confusion, that is exactly my point. If one of your co-workers
b) Use a static/fixed value that is defined by convention, i.e. is not
platform-dependent.
I vote for b). We recently had an encoding problem when we built a
project that was developed on Windows on a Unix server. Fortunately,
it caused a syntax error so that it was detected early. I can
Roger Ye wrote:
But is'nt this more an argument for get used to explicitly state
encoding than for
a maven wide default is better than a platform wide default?
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same applies to locking down plugin
Benjamin Bentmann schrieb:
Roger Ye wrote:
But is'nt this more an argument for get used to explicitly state
encoding than for
a maven wide default is better than a platform wide default?
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Paolo Compieta wrote:
- most companies have uniform OS platforms
I am used to scenarios where people work on Unix/Win terminals or their
Unix/Mac/Win notebooks on their own discretion, creating quite some
heterogenous development
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
Roger Ye wrote:
On 4/29/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
Manos Batsis wrote:
Having all files stick to a given (default) encoding will mean a
nightmare to all
platforms where such encoding is not the system one when it comes to
modifying or editing files.
I can't follow your
Rainer Pruy wrote:
I'm still not convinced that we will get their by trading one problematic
default for another.
I am not saying that this is the ultimate solution. I only believe it's a
compromise and improvement until we can introduce a new POM version in Maven
2.1, comparable to the Maven
Manos Batsis wrote:
I hate this! Someone finally agrees with me but in a misquoted email; I
never wrote that :-)
As I said, that was my fault of getting the reply header wrong, I apologize
for this confusion. I didn't want to upset you Manos.
Benjamin
Benjamin Bentmann schrieb:
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
Benjamin Bentmann schrieb:
Rainer Pruy wrote:
I'm still not convinced that we will get their by trading one problematic
default for another.
I am not saying that this is the ultimate solution. I only believe it's a
compromise and improvement until we can introduce a new POM version in
Rainer Pruy wrote:
This might be true for an all java world,
nevertheless, in case the maven default deviates from your platform one,
how does an editor know where to get the proper encoding for a given file?
(It would be quite difficult to enrich *any* editor around with some logic
to default
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
Old projects moving to new Maven builds will need to add a single
property in their pom, and then everything compiles fine etc. I
consider this maintenance and
Benjamin Bentmann schrieb:
Rainer Pruy wrote:
This might be true for an all java world,
nevertheless, in case the maven default deviates from your platform one,
how does an editor know where to get the proper encoding for a given
file?
(It would be quite difficult to enrich *any* editor
Roger Ye wrote:
we can survive if we explicitly set the source file encoding in the
project
pom.xml
Yes, this is right, explicitly setting the encoding is the golden answer.
But will you do so right from the beginning if your platform default
encoding happens to build as you expect or will
Wayne Fay wrote:
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
It's right that's old projects are not affected as long as we assume they
have locked down their plugin versions. The change we discuss
Wayne Fay schrieb:
Correct me if I'm wrong, but old projects using old Maven builds will
not be affected by this. So we eliminate those from the discussion.
Old projects moving to new Maven builds will need to add a single
property in their pom, and then everything compiles fine etc. I
Hi,
On 4/30/08, Benjamin Bentmann [EMAIL PROTECTED] wrote:
I agree, having users explicitly state the encoding in their POMs is the
best we can have, the same applies to locking down plugin versions by the
way. No guessing, no implicit default values, just full control, let's call
it heaven
+1 for a)
- People that don't care about it don't need to worry
- It works similarly within groups that share the same encodings
- When it breaks, because cross-unicode-script contributors are involved,
then it needs to be specified in the pom.
The downside of b) is that it forces all those who
+1 for a)
with a warning like [WARN] using detected local platform encoding 'xxx'. To
ensure build reproducibility, consider adding project.build.sourceEncoding
property to your pom
This won't break existing builds from users that don't even know their
encoding, but will help them do the right
for maven 2.0.x i would go +1 for option a
for maven 2.1 I would go +1 for option b with my caveat being a proper
element of the pom and not shoved into the properties.
jesse
--
jesse mcconnell
[EMAIL PROTECTED]
-
To
Roger Ye wrote:
For projects involving developers from different country (i.e. the
developers use different default encodings from one to another), it's a
must
for everyone in the team / project to understand that his/her default
encoding is not the default for others
Yes, it would be great
Rainer Pruy wrote:
If already being unpolite why not in a way that will cause major
improvement on the situation by forcing users to stating encoding in any
case
Yes, as we talk about it, this becomes my personal favorite. I guess a
default value as originally proposed is only of value if it
walid joseph Gedeon wrote:
Note: it would probably be a good idea to include the encoding used
(whether
default or set) in the plugin report information.
Which kind of plugin report information are you referring to? E.g. where
exactly should the encoding used by the Maven Compiler Plugin be
Benjamin Bentmann wrote:
Marat Radchenko wrote:
And let it be UTF-8.
Until a flood of users pushes into this direction of UTF-8,
which is surely the more international/nicer choice, I believe we're better
off with staying to Latin-1 and keep consistency among the plugins.
OK, start the
61 matches
Mail list logo
