Very Briefly for the Impatient

Java code generated by Altova MapForce in the “com.altova” package and sub-packages may differ between different mappings. It is not possible to create a common library and reuse it between different mappings without risking errors.

The Slightly Longer Version

At the office we use Altova’s MapForce to create mappings and conversions between different formats and, as far as I am concerned, it is a nice application.
When MapForce generates Java code from a mapping, one can chose a package name in which what we assumed were the mapping-specific code was generated. In addition, there is a significant amount of code generated in the “com.altova” package and sub-packages. Given that we were not able to change the package name for this code and noting that classes with the same names were generated in these packages when generating code for multiple mappings, we assumed that this code was some kind of common code and that we could extract it to a library and reuse this between mappings.

Recently we discovered that this is not the case – code within a class with the exact same name in the “com.altova” package (or sub-packages) may vary depending on the mapping.
Altova suggests putting all mappings in one and the same MapForce project and generating code for the whole shebang at the same time.
As we are looking at a very large number of mappings, this does not seem like a very practical approach to me. In addition, we aspired at re-using mappings in several projects and under such circumstances it would be bad if two mappings contained two classes with the same name located in the same package (assuming you put all the generated code in a mapping library).

Let’s see if Altova comes up with something that can solve this problem or if we have to revert to duplicating almost-identical code in each mapping as well as moving the classes in the “com.altova” package. I will keep you posted!

Update

After further investigations I have learned that the code templates used by MapForce when generating code are located in the “spl” directory in the MapForce installation directory. These code templates can, and do, contain meta-programming if-statements that, depending on parameters given the code generation, will be able to select whether or not to generate some block of code. The following is an example from the XmlTreeOperations.java file:

[if $GeneratedWrapperStyle = 2]        
    private static XmlFormatter getFormatter(MemberInfo member)
    {
        if (member.getDataType().getFormatter() != null)
            return (XmlFormatter) member.getDataType().getFormatter();
        else
            return (XmlFormatter) Xs.AnySimpleTypeFormatter;
    }
[endif]

You may, like me, be tempted to modify these code templates as to assure that the code in the com.altova package will always be identical. Doing so will, however, void your right to support, according to communication I have had with Altova.
As of writing this article, the above kind of meta-programming statements is limited to about 10 template files. The mere presence of this option cause me to regard creating a common library from the com.altova classes generated at different points in time (albeit with the same version of MapForce) as not being an option. The reason is that I do not know what Altova will come up with in future versions and, while it may seem manageable today it may not be tomorrow.

Refactoring Generated Code

“Why don’t you move the classes in the com.altova package to some other package that is unique among the mappings you have?”
This seems like the approach that I would suggest, unless you are able to generate code for all your mappings at once.
It is not as easy as it sounds, since the generated code uses fully-qualified class names like in this example:

com.altova.io.FileInput

If there had been import statements, the IDE would have been able to aid me to a much larger extent.

Conclusion

• I can only recommend creating a common library of parts of the code generated by MapForce if you always generate code for all your mappings at the same time.
• Refactoring generated code as to avoid classes with the same name located in identical packages in order to avoid possible class-loading confusion when code generated from multiple mappings at different points in time will be somewhat time-consuming and error prone.
• If you have a Support & Maintenance Package from Altova, their customer service is good.