Le samedi 29 mars 2008, Benjamin Bentmann a écrit :
> > The convention has to be shared between every plugin and the super POM. I
> > dislike the pure formal convention, that every plugin would copy/paste.
> > Coded as an API like "String checkSourceEncoding(String encoding)" method
> > to
> > Abst
Le samedi 29 mars 2008, Brian E. Fox a écrit :
> Hi Herve, Yes those can be changed as I used the shell execution to try
> and force the options. You should be able to edit directly with your
> account.
>
>
> -
> To unsubscribe, e-
Hi Herve, Yes those can be changed as I used the shell execution to try
and force the options. You should be able to edit directly with your
account.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [E
> Otherwise, plugins should by convention agree to handle a null value for
> the encoding parameter to denote some fixed encoding. This way,
> upgrading
> Maven will not affect the default encoding behavior.
The convention has to be shared between every plugin and the super POM. I
dislike the pu
Le samedi 29 mars 2008, Benjamin Bentmann a écrit :
> > core plugins to be modified:
>
> I moved this list over to the wiki article [0] in Confluence, think it's
> easier to maintain there instead of being splattered through this mailing
> thread.
great
I added a link in http://docs.codehaus.org/di
core plugins to be modified:
I moved this list over to the wiki article [0] in Confluence, think it's
easier to maintain there instead of being splattered through this mailing
thread.
> This in place, plugin parameters could be written like
>
> /**
>* @parameter expression="${encoding}"
> > Le mardi 25 mars 2008, Brian E. Fox a écrit :
> > > Nope, nothing funky about the maven on there, the base 2.0 is the 2.0.8
> > > package.
> > >
> > > -Original Message-
> > > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
> &g
Le mercredi 26 mars 2008, Benjamin Bentmann a écrit :
> > What about just unifying the expressions that refer to encoding in
> > plugins?
>
> As an intermediate solution until Maven 2.1 provides an extended POM, this
> seems like a good approach.
+1
core plugins to be modified:
- compiler
- javadoc
gt; Le mardi 25 mars 2008, Brian E. Fox a écrit :
>
> > Nope, nothing funky about the maven on there, the base 2.0 is the 2.0.8
> > package.
> >
> > -Original Message-
> > From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, March 25, 2008 5:02
gt; -Original Message-
> From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 25, 2008 5:02 PM
> To: Maven Developers List
> Subject: Re: Maven and File Encoding
>
> > Assuming I didn't mess up the config (you can see the execution at the
> >
What about just unifying the expressions that refer to encoding in
plugins?
As an intermediate solution until Maven 2.1 provides an extended POM, this
seems like a good approach.
javadoc-plugin has ${encoding}
compiler-plugin has ${maven.compiler.encoding}
resources-plugin has no expression
I've encountered this in the IDE integration for netbeans when I want
to allow users to set encoding for the project. Currently I'm setting
configuration for compiler-plugin and resources-plugin but that's
cumbersome.
On Wed, Mar 26, 2008 at 11:37 AM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
There is one feature in this patch I don't like: you hardcoded a default
encoding to ISO-8859-1 instead of no default value (which means platform
encoding).
Indeed, I also suggested using a fixed default value for other plugins:
- MCOMPILER-63
- MJAVADOC-165
- MRESOURCES-57
I simply chose Latin
> I haven't had yet the time to setup some nice IT for this, but the fix is
> here: MPLUGIN-101.
great!
There is one feature in this patch I don't like: you hardcoded a default
encoding to ISO-8859-1 instead of no default value (which means platform
encoding).
I understand that platform encoding
Nope, nothing funky about the maven on there, the base 2.0 is the 2.0.8
package.
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2008 5:02 PM
To: Maven Developers List
Subject: Re: Maven and File Encoding
> Assuming I didn't mes
Assuming I didn't mess up the config (you can see the execution at the
beginning of the console output) it seems to be running without any
errors so far.
Hm, both theory and practice tell me that reading ASCII files with UTF-16
encoding is a rather bad idea, so the build must fail if properly
co
: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 6:34 PM
To: Maven Developers List
Subject: Re: Maven and File Encoding
> I can setup an alternate build for Maven.
Cool, thanks Brian.
> What java options do I need to set to change the encoding?
Setting the
I can setup an alternate build for Maven.
Cool, thanks Brian.
What java options do I need to set to change the encoding?
Setting the system property "file.encoding" should do:
-Dfile.encoding=UTF-16
either via MAVEN_OPTS or directly on the java command line.
Benjamin
---
I can setup an alternate build for Maven. What java options do I need to
set to change the encoding?
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2008 6:12 PM
To: Maven Developers List
Subject: Re: Maven and File Encoding
> But if we do
But if we do so on a whole CI server, I fear the havoc will be bigger than
expected
I surely did not mean to do this immediately for the main CI builds. Given
Maven's current state, it's some future goal. Maybe we could setup a
secondary CI build job for this, such that people working on the enc
I like the idea: easier to do than having access to a Z/OS box (anyone able to
deploy a CI on a Z/OS box?), even if every aspect is not covered (for example
it doesn't fail if encoding parameter has not been set in compiler plugin)
But if we do so on a whole CI server, I fear the havoc will be b
It might be a good idea to run CI with IBM JDK even on more common
hardware. For example, I could not build maven with IBM JDK last time I
tried. I did not have much time to investigate, but it looked like IBM
JDK could not read modello's pom.xml as UTF-8.
--
Regards,
Igor
Hervé BOUTEMY wrote
AFAIK, the problem doesn't show for japanese nor chinese developers: even in
Japan or China, platform encoding on Unix or Windows is ASCII based,
precisely to avoid problems on "simple" ascii characters
like Benjamin says, the encoding issue is more subtle
There is one situation I know for this
does this mean maven actually never worked fro japanese or chinese
developers?
It depends: As long as one sticks to US-ASCII when editing source files and
uses a platform encoding that has US-ASCII as a subset (UTF-8, Latin-X,
...), you won't notice Maven's misbehavior. Also, using Non-ASCII c
just curious..
does this mean maven actually never worked fro japanese or chinese developers?
Milos
On Fri, Mar 21, 2008 at 8:15 PM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> There are still several code spots in Maven that rely on the platform's
> default encoding when processing
Hi,
There are still several code spots in Maven that rely on the platform's
default encoding when processing text files which does support build
reproducibility. It could help developers to detect such defects if the CI
machines were configured to run Maven with
MAVEN_OPTS=-Dfile.encoding=U
26 matches
Mail list logo
