I have a java artifact dual-built for both linux & IBM mainframe, all the dependent shell scripts (in /sbin dir) are initially written in ASCII but are copied to another directory (in /sbin-ebcdic). So I configure the maven-resources-plugin to do it for me:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>3.0.1</version>
<executions>
<execution>
<id>copy-sbin</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.basedir}/sbin-ebcdic</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/sbin</directory>
</resource>
</resources>
<encoding>IBM037</encoding>
</configuration>
</execution>
</executions>
</plugin>
While it does copy the entire directory, all files in them are still in UTF-8 encoding, as if my:
<encoding>IBM037</encoding>
setting doesn't exist. Why the maven-resources-plugin doesn't function as intended? Is it a bug?
If you read the documentation carefully of resources:copy-resources, it says this about <encoding>
:
The character encoding scheme to be applied when filtering resources.
If you are not doing filtering, the resources
plugin will simply do a byte-for-byte copy. If you want it to transform the resources using the specified encoding, you need to enable filtering, even though you aren't using property interpolation.
EDITED:
I just confirmed it. The specified encoding is used both when reading and writing the file, which seems counter-intuitive. If you take a look at line 144 in DefaultMavenFileFilter.java
in the dependency chain of maven-resources-plugin:3.0.1
:
143 fileReader = getFileReader( encoding, from );
144 fileWriter = getFileWriter( encoding, to );
145 Reader src = readerFilter.filter( fileReader, true, wrappers );
146
147 IOUtil.copy( src, fileWriter );
When I changed the encoding of getFileWriter()
to UTF-8
while debugging, it worked as one would expect.
Basically, you have a couple of options:
<outputEncoding>
configuration parameter.