The build for apache FOP produces a jar which includes partial subsets of classes from commons-io, commons-logging, and avalon. By doing this, it will potentially destabilize applications that are dependent on these libraries. Many web-application containers do not specifically enforce load order of jars and as a result if the pdf-transcoder.jar from 0.94 (and whatever it is in later releases) is loaded before the proper commons-io, commons-logging etc jar files it will cause signature errors and other runtime errors to occur. I discovered this while using the Eclipse BIRT Report Engine in a non-osgi fashion within a web application. My application logic utilizes a much newer version of commons-io. Please remove the "import" or "merging" of these class file subsets from the build process and add a dependency on the full jars in question.
I think the reason these classes have been put in there is to allow the transcoder JAR to be used as a stand-alone JAR. I could be wrong, but I don't think the intention was for users to include it in the class path. There are two JARs one with just the FOP specific classes and an all-in-one version. Which one are you using?
I think that this might not be a bug with FOP but with Eclipse BIRT. I'll have to circle with them and determine why the jar is included in the dependencies of BIRT. As it stands right now, there is a collision that is causing problems when BIRT is deployed in a webapp using the maven dependencies for 3.7.2 (I think) and I have to recheck the versions. At this time, close this as won't fix. If I can determine the issue on the BIRT or possibly Batik side (which is also depended on by BIRT) I'll open a bug where appropriate.
Thanks David. I'm closing the bug as requested.