JAR building question

[Frank Griffin <ft...@ntplx.net>]

This isn't a Xerces question per se, but it deals with packaging files, so I figured somebody here has probably run into this before....

The issue is building an application JAR file on one platform, and then distributing it to others.  Specifically, I am building Xerces, Xalan, and FOP on OS/2, and sending them up to OS/390.  The problem occurs when a JAR contains a text file element, e.g. a *.properties file.  The file will be built into the JAR using the native encoding for the platform on which it is produced, but when it is accessed during execution on the target platform, it will be assumed to be in the native encoding for *that* platform.  In most cases, this doesn't matter, because such files tend to stick to US-ASCII, but when shipping JARs between ASCII-based systems and EBCDIC-based systems, it fouls up.

Obviously, one solution is to build open-source stuff on the intended target; however, that doesn't work for vendors who want to ship JARs and not unpacked trees containing files with different FTP transfer rules.

A question is whether it is considered "standard" (it's obviously common sense) for software producers to preprocess any non-binary files in their jars with native2ascii, so that at least the guy on the non-standard platform knows that he's starting from vanilla ASCII, regardless of what his own platform needs to convert it to.

A second question is whether there is any "standard" tool for going through a .zip/.jar file, identifying textual files, and converting them to a different encoding on the fly, leaving the binaries unchanged.  This seems like it would be pretty simple to do using the java.util.jar and java.util.zip stuff, but if someone's already done it, I'd rather not do it again.

Thanks for your time on this.

Frank Griffin