On 1-May-08, at 2:13 AM, Benjamin Bentmann wrote:
Jason van Zyl wrote:
> and as such warning is most appropriate
> rather than simply info. I could be talked into accepting an info
that
> has "build not fully reproducible etc" text in it, but this is
> splitting hairs.
>
It can in no way
Dennis Lundberg wrote:
As long as there is an easy way for users to get rid of the warning, which
seems to be the case here.
Yes, simply setting the POM property ${project.build.sourceEncoding} to some
value, either XYZ or if users really want ${file.encoding}, will disable the
warning.
B
Benjamin Bentmann wrote:
Brian E. Fox wrote:
Is a warning really needed? Perhaps just an INFO that says "using
platform
default encoding: [value]". Again going under the theory that someone
that
needs to worry about the encoding will be looking for it, shoving a
warning in everyone's face tha
Jason van Zyl wrote:
> and as such warning is most appropriate
> rather than simply info. I could be talked into accepting an info that
> has "build not fully reproducible etc" text in it, but this is
> splitting hairs.
>
It can in no way effect what currently happens even if it's not 100%
opi
I'm fine with the warning, you convinced me.
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 30, 2008 2:22 PM
To: Maven Developers List
Subject: Re: POM Element for Source File Encoding
> I agree and we can do this for 2.1. We can
> I agree and we can do this for 2.1. We can't break the existing contract
> which can potentially screw a lot of people.
No one is proposing changing things for 2.0. If no encoding is
declared, it will use the system default, as it has always done.
We're just talking about INFO vs WARNING for in
On 30-Apr-08, at 11:02 AM, Wayne Fay wrote:
This idea with the warning was also proposed by two or three users
on the
list, especially Hervé put it nicely [0]. I took this happily up
because I
(still) believe that having builds out there which implicitly rely
on the
platform encoding and
> This idea with the warning was also proposed by two or three users on the
> list, especially Hervé put it nicely [0]. I took this happily up because I
> (still) believe that having builds out there which implicitly rely on the
> platform encoding and as such just break with the ideals of
> platfo
Brian E. Fox wrote:
Is a warning really needed? Perhaps just an INFO that says "using platform
default encoding: [value]". Again going under the theory that someone that
needs to worry about the encoding will be looking for it, shoving a
warning in everyone's face that doesn't care isn't a great
>I would like to start adopting the plugin sources to
>- have their encoding parameter default to null, meaning platform encoding
> as before
Yep.
>- output a warning message if the encoding is unspecified
Is a warning really needed? Perhaps just an INFO that says "using platform
default encod
Brian E. Fox wrote:
I'd say based on the various points brought up by the users that platform
encoding as the default makes the most sense.
Yes, that's the majority's sense. I counted roughly but so far the ratio of
votes is about 3:1 for keeping platform encoding as default vs. Latin-1,
takin
CTED]
Sent: Tuesday, April 29, 2008 9:08 AM
To: Maven Developers List
Subject: RE: POM Element for Source File Encoding
>> Is there an issue with a huge number of votes attached to it?
>To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
>but has (excluding myself)
>> Is there an issue with a huge number of votes attached to it?
>To my knowledge, no. We have MNG-2216 that is quite similar to our proposal
>but has (excluding myself) only three other votes which is not that much.
>Let my point out that the encoding issue is subtle and I expect a fair
>amount
Brian E. Fox wrote:
Who exactly is asking for this change?
Basically only me, in an attempt to guarantee reproducible builds by
eliminating a dependency on an environmental property.
Is there an issue with a huge number of votes attached to it?
To my knowledge, no. We have MNG-2216 that is
Bentmann [mailto:[EMAIL PROTECTED]
Sent: Monday, April 28, 2008 4:51 PM
To: Maven Developers List
Subject: Re: POM Element for Source File Encoding
Hervé Boutemy wrote.
> the proposal is here:
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Recently, we have re
Hervé Boutemy wrote.
the proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Recently, we have received two comments from users on the wiki that are
against the proposed default encoding of Latin-1 but would rather like it to
stay as is, i.e
Thanks Milos for this review.
I'm starting to merge changes into plugins trunks.
Hervé
Le mercredi 16 avril 2008, Milos Kleint a écrit :
> +1 on integrating it.
> it's non intrusive and does what I would expect by default while
> allowing me to override the behaviour for some plugins.
> it makes
Hervé BOUTEMY <[EMAIL PROTECTED]> wrote:
> another try...
>
> the proposal is here:
>
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
>
> I did the work on 2 plugins in a branch:
> - jxr: http://svn.apache.org/viewvc?rev
another try...
the proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
I did the work on 2 plugins in a branch:
- jxr: http://svn.apache.org/viewvc?rev=645260&view=rev
- javadoc: http://svn.apache.org/viewvc?rev=645262&view=rev
As you can
p://docs.codehaus.org/display/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 Elemen
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
> 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é
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.
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 chan
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
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
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
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.
>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
>
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,
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
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 er
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.
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 forgo
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 undeclare
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 t
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 there
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 simp
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 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
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 whe
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 Java
+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
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 bef
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 peekin
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
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 builds
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
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 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, Jaso
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 t
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 http://svn.apache.org/viewvc/maven/sandbox/branches/MNG-
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, t
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 se
by each
> and every plugin,
> 2. a default value set to ISO-8859-1 (instead of platform encoding) to have
> build reproducibility by default
>
> The full proposal is here:
>
> http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
>
> As
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, 2008
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 p
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 s
> > 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 build reproducibility by default
> > >
> > > The full proposal
ncoding) to
> > have build reproducibility by default
> >
> > The full proposal is here:
> >
> > http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
> >
> > As you'll see, we've already found 8 Apache plugins to change, and 4
platform encoding) to have
build reproducibility by default
The full proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus
ones. Before starting the code modification
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 a
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 Latin
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)
sour
fault
The full proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
As you'll see, we've already found 8 Apache plugins to change, and 4
Codehaus
ones. Before starting the code modifications, we need everybody to
agree on
the proposal (an
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
(instead of platform encoding) to
have
build reproducibility by default
The full proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
As you'll see, we've already found 8 Apache plugins to change, and 4
Codehaus
ones. Before startin
tion 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
> build reproducibility by default
>
> The full proposal is here:
>
> http://docs.codehaus.org/display/MAVENUSER/POM+Elemen
build reproducibility by default
The full proposal is here:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
As you'll see, we've already found 8 Apache plugins to change, and 4 Codehaus
ones. Before starting the code modifications, we need everybody to agr
Please put it on the user proposal page on the wiki so we don't lose it.
Done:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
Ciao!
Benjamin Bentmann
-
To unsubscribe, e-mail: [
This seems logical to me. Please put it on the user proposal page on the
wiki so we don't lose it.
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 17, 2008 2:30 PM
To: Maven Developers List
Subject: POM Element for Source File Encoding
Dear Developers,
a couple of plugins processes the contents of source files, e.g.
maven-resources-plugin, maven-compiler-plugin, maven-javadoc-plugin and
taglist-maven-plugin to name just a few. Unlike XML files, Java source files
have no intrinsic means of determining the required character enco
75 matches
Mail list logo
