One thing we could try is to pass in FOP's home directory through a system property so cli.Main has a better chance of building the right classpath when the batch file is not called from FOP's home directory. That way we could avoid the fixed list of JARs and the proposed batch file magic that may only be available on the latest Windows versions.
And yet another possibility could be an EXE file which takes the role of fop.bat and starts up the JVM. But that's quite a bit more work and will involve the use of a programming language and compiler that not everyone is comfortable with or has available. On 06.01.2007 11:06:08 Simon Pepping wrote: > On Sat, Jan 06, 2007 at 02:48:52AM +0100, Christian Geisert wrote: > > Simon Pepping schrieb: > > >According to the documentation page fop may be run as: > > > > > >"java -jar build/fop.jar". > > > > > >In our own bin packages that does not work, because the manifest file > > >lists the libraries without a path. Does that have a special reason? > > >I think it would be better to change it to ../lib/xxx.jar. > > > > Did you try to run it this way? It works for me (due to some dynamic > > classpath magic done by Jeremias). > > > > See http://issues.apache.org/bugzilla/show_bug.cgi?id=38821 for some info. > > I see, it is a done discussion. I tend to agree with Werner Donné's > former point of view, viz. that the bin package needs to be > consistent. The classpath mechanism is a distribution level > mechanism. If we do not want to make it work in our bin distribution, > we might as well omit it entirely. But that brings me back to > Jeremias' original implementation, and that ground was covered in the > discussion as well. > > As it is, I will adapt the relevant section in the running FOP web > page. > > Regards, Simon > > -- > Simon Pepping > home page: http://www.leverkruid.eu Jeremias Maerki