Hi Paul,
Author: pgier
Date: Mon Oct 4 22:22:30 2010
New Revision: 1004461
URL: http://svn.apache.org/viewvc?rev=1004461&view=rev
Log:
[MANTRUN-155] Set encoding for generated Ant build. Patch from Anders Hammar
with some minor changes.
Added:
maven/plugins/trunk/maven-antrun-plugin/src/it/task-encoding-test/
maven/plugins/trunk/maven-antrun-plugin/src/it/task-encoding-test/pom.xml
(with props)
Modified:
maven/plugins/trunk/maven-antrun-plugin/src/main/java/org/apache/maven/plugin/antrun/AntRunMojo.java
+ String encoding = project.getProperties().getProperty(
"project.build.sourceEncoding" );
+ if ( encoding == null )
+ {
+ encoding = DEFAULT_ANT_BUILD_ENCODING;
+ }
This approach violates the usual usage pattern for the source encoding
as outlined in [0]. First, the direct query to the property cuts off the
future migration to a POM element. Second, the default value for the
property is not UTF-8 but the platform encoding.
Given that the build file for Ant is auto-generated and not meant for
human consumption/editing, I don't see any reason why its encoding
should be configurable by the user and be linked to the sourceEncoding
property. As such, why not keept it simple and just always use UTF-8 for
the encoding? Always using UTF-8 also ensures that the build file can be
written at all, even if project.build.encoding is set to a charset that
can't represent the characters given in the POM.
Benjamin
[0]
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org