Benjamin Bentmann wrote:
Unfortunately, the change for MJAVADOC-165 was already released, i.e. the
Javadoc Plugin 2.4 uses Latin-1 as default encoding if its configuration
does not specify otherwise. As a matter of consistency, this should be
reverted to use platform encoding, however this would
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 enco
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 sou
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, star
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 b
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 w
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
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 unsubscri
+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 righ
+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 d
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 "
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
> in their pom, and then everything compiles fine etc. I
> consi
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 is
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
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 *a
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
in their pom, and then everything compiles fine etc. I
consider this "maintenance" and based
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
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 vers
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
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
--
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
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 yo
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
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 dev
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
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 plug
> 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 im
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
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 consiste
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
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
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.
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 t
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
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]
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
> > platf
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 e
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], whe
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 explic
----------
> 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 the Maven - Users mailing list archive at Nabble.com.
-
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 o
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]
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 encodi
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
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 dis
+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
>
> *
aus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
Vi
, 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.
A
+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
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
> plat
+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 c
+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 art
+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
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 g
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
+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 don
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 res
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 me
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 acr
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
+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 enc
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 s
62 matches
Mail list logo