Summary: | The manifest file no longer has a Class-Path entry | ||
---|---|---|---|
Product: | Fop - Now in Jira | Reporter: | Werner Donné <werner.donne> |
Component: | general | Assignee: | fop-dev |
Status: | CLOSED WONTFIX | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 0.91 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Attachments: | Ant 1.6.2 output |
Description
Werner Donné
2006-03-01 17:54:01 UTC
Right, the Class-Path entry has been removed. The Main-Class entry is still there. As compensation for removing the very static Class-Path entry the main class has been extended to dynamically build the right classpath for FOP taking all JAR files in the lib directory into account not only the ones in the Class-Path list. So, this is not a bug, but a feature. :-) Did you actually try running "java -jar fop.jar"? It works fine for me. If it doesn't for you, please reopen the issue and tell me what the problems are so I can have a look. If you into the build directory it works, but from anywhere else it doesn't: java -jar file:/var/local/fop-0.91beta/build/fop.jar in my home directory gives: Unable to start FOP: java.lang.RuntimeException: fop.jar not found in directory: /home/werner (or below) at org.apache.fop.cli.Main.getJARList(Main.java:58) at org.apache.fop.cli.Main.startFOPWithDynamicClasspath(Main.java:118) at org.apache.fop.cli.Main.main(Main.java:202) The second problem is that another tool can't refer to fop.jar by putting it in the Class-Path entry of its manifest file. It doesn't matter if you are in the build directory or not. In my opinion the regular extension mechanism should be used. There is nothing static about it. This is a build matter where you keep the manifest file up-to-date when you produce a consistent distribution. That looks like a malformed URL to me. Have you tried it this way? java -jar file:///var/local/fop-0.91beta/build/fop.jar The -jar option expects a file not a URL. (In reply to comment #2) > If you into the build directory it works, but from anywhere else it doesn't: > > java -jar file:/var/local/fop-0.91beta/build/fop.jar > > in my home directory gives: > > Unable to start FOP: > java.lang.RuntimeException: fop.jar not found in directory: /home/werner (or > below) > at org.apache.fop.cli.Main.getJARList(Main.java:58) > at org.apache.fop.cli.Main.startFOPWithDynamicClasspath(Main.java:118) > at org.apache.fop.cli.Main.main(Main.java:202) Ok, I see the problem. Turns out there really is a downside to my approach. I have no way of retrieving the location of fop.jar without resorting to accessing Sun-specific classes (sun.misc.Launcher). Too bad however, that the "Class-Path" approach is also flawed. That's why I actually implemented the dynamic class path approach. > The second problem is that another tool can't refer to fop.jar by putting it in > the Class-Path entry of its manifest file. It doesn't matter if you are in the > build directory or not. Just curious: What's the use case here? > In my opinion the regular extension mechanism should be used. There is nothing > static about it. This is a build matter where you keep the manifest file > up-to-date when you produce a consistent distribution. You mean I should revert the change? I guess there's no harm if I simply add the Class-Path entry again. The dynamic approach is only triggered if either Batik or Avalon-Framework is not found in the class path. Any other opinions, fop-devs? > > The second problem is that another tool can't refer to fop.jar by putting it in > > the Class-Path entry of its manifest file. It doesn't matter if you are in the > > build directory or not. > Just curious: What's the use case here? This is part of the extension mechanism. One JAR can declare the classpath it needs, without needing a global classpath. If you have several JARS with their own dependencies on a classpath, the builder of the global classpath would require all that knowledge and the global classpath might have conflicts for several of the classpaths. Sometimes it is not even possible to rely on a global classpath, in an EAR file for example. Security is another use case. Think of the sandbox. My personal use case is CSSToXSLFO (http://www.re.be/css2xslfo), which has a package variant for FOP. Werner, would you please check if my change works for you now? http://svn.apache.org/viewcvs?rev=382152&view=rev Created attachment 17817 [details]
Ant 1.6.2 output
(In reply to comment #8) > Created an attachment (id=17817) [edit] > Ant 1.6.2 output > Yes, and now? The output simply shows that you didn't put the OFFO Hyphenation Pattern JAR in the lib directory and that's why it can't run the hyphenation tests. The build is fine otherwise. If you just want to build FOP but skip the tests you can run "ant package". That works, but now we have the same problem as with version 0.20.5. The manifest file refers to the libraries as if fop.jar is a sibling of them. So the outcome of the build is not consistent. Either fop.jar is also copied to the lib directory, or the manifest file of fop.jar puts "../lib" in the paths of the libraries. That's exactly why I don't like the Class-Path entry. You have to specify a definitive location for the JARs. When you deploy an application you normally don't care about the setup in the development environment. You simply pack the necessary JARs together. That's why I'm strongly for leaving the Class-Path entry like it is right now and that you copy fop.jar over into the lib directory. Otherwise next time, someone else comes and says: Why do I have to place fop.jar in a different location that the other JARs? The alternative you have is to create a simple Ant script that will patch fop.jar's manifest exactly the way you want it. You are right. This is the best solution. Thank you very much for your efforts. The classpath entry gives a long list of stacktraces in Glassfish 3.1... and I think Glassfish is right. The classpath entry doesn't reflect the dependencies documented at http://www.linuxfromscratch.org/blfs/view/svn/pst/fop.html . It is trying to load things which aren't really required (xml-apis.jar, xerces, ...) and would cause problems here. Glassfish complains that those resources are missing (which is right). I think the best thing to do is to remove the classpath entry (at least everything that isn't required). Yes, running fop.jar should imply passing the correct classpath. You can do that with environment variables or better, batch / shell script files if you want. batch transition resolved+wontfix to closed+wontfix batch transition resolved+wontfix to closed+wontfix; if you believe this remains a bug and can demonstrate it with appropriate input FO file and output PDF file (as applicable), then you may reopen |