2

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?

tribbloid
  • 4,026
  • 14
  • 64
  • 103
  • Please be noted that resource filtering is disabled so this problem: http://stackoverflow.com/questions/14327003/wrong-encoding-after-activating-resource-filtering is out of the picture. – tribbloid Oct 17 '16 at 21:50

1 Answers1

2

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:

  • Write your own plugin. It's not that hard for this type of use-case.
  • File an improvement ticket (I am thinking about doing this myself if you don't) with the maintainers to introduce an <outputEncoding> configuration parameter.
  • If you're in a pinch, create your own fork of the plugin. Obviously it would be great if you could contribute your work to the main development stream.
Daniel
  • 4,033
  • 4
  • 24
  • 33
  • Been there tried that, with true under the copied files are still in UTF-8. This also contradicts with http://stackoverflow.com/questions/14327003/wrong-encoding-after-activating-resource-filtering. I otherwise completely agree with you on the documentation :) – tribbloid Oct 18 '16 at 20:45
  • I got it to work, sort of. I had a text file with Swedish diacritics in ISO-8859-1 and used your configuration to copy it using UTF-8. It obviously touched file, but the result wasn't what I expected (it applied the UTF-8 encoding while _reading_ the file). I'll run the plugin in the debugger to see what's going on. – Daniel Oct 19 '16 at 04:54
  • Please see my latest **EDITED** section above. – Daniel Oct 19 '16 at 14:44
  • Wow that's some hardcore discovery, I'll try to post on their issue tracker – tribbloid Oct 19 '16 at 17:56
  • Posted as https://issues.apache.org/jira/browse/MRESOURCES-232, thanks again for figuring this out! – tribbloid Oct 19 '16 at 21:50
  • Developer here, I have modified the issue off a bug because it isn't one. The mojo is `copy-resources` and not `convert-resources` (`iconv`) style. It would probably make sense to have something like this. – Michael-O Oct 25 '16 at 09:26
  • Fair enough. Thanks for the prompt response. I agree that it isn't a bug, but a nice-to-have feature since the mojo is indeed reading and (re)writing the resource file. – Daniel Oct 25 '16 at 09:35
  • @Daniel Attention, this mojo is solely for copying resources no more, no less. I am inclined to have a `transform-resources`. `copy-resources` would be a simpler case for the former: `encoding` and `outputEncoding`. – Michael-O Oct 25 '16 at 09:41
  • @Michael-O Absolutely, I am a big fan of _separation of concerns_. It makes more sense to have separate mojos for this. – Daniel Oct 25 '16 at 09:44
  • @tribbloid If you still need this, please change your issue accordingly. – Michael-O Oct 25 '16 at 09:50