Bug 38821 - The manifest file no longer has a Class-Path entry
Summary: The manifest file no longer has a Class-Path entry
Status: CLOSED WONTFIX
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.91
Hardware: All Linux
: P2 normal
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-01 17:54 UTC by Werner Donn
Modified: 2012-04-30 00:17 UTC (History)
0 users



Attachments
Ant 1.6.2 output (88.17 KB, text/plain)
2006-03-02 11:13 UTC, Werner Donn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Werner Donn 2006-03-01 17:54:01 UTC
The manifest file no longer has a Class-Path entry. Why is this? Now it is no
longer possible to run FOP with "java -jar fop.jar" or to launch another
application this way that refers to fop.jar in its manifest file.

Version 0.20.5 did have such an entry, but the error there was that fop.jar
resided in the "build" directory, while the other JARs were in the "lib"
directory. The fop.jar manfest file, however, expected to be a sibling of the
others.
Comment 1 Jeremias Maerki 2006-03-01 18:18:17 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.
Comment 2 Werner Donn 2006-03-01 18:31:47 UTC
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.
Comment 3 Clay Leeds 2006-03-01 18:35:49 UTC
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
Comment 4 Werner Donn 2006-03-01 18:45:05 UTC
The -jar option expects a file not a URL.
Comment 5 Jeremias Maerki 2006-03-01 20:13:24 UTC
(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?
Comment 6 Werner Donn 2006-03-01 20:23:16 UTC
> > 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.
Comment 7 Jeremias Maerki 2006-03-01 21:50:21 UTC
Werner, would you please check if my change works for you now?
http://svn.apache.org/viewcvs?rev=382152&view=rev
Comment 8 Werner Donn 2006-03-02 11:13:26 UTC
Created attachment 17817 [details]
Ant 1.6.2 output
Comment 9 Jeremias Maerki 2006-03-02 13:25:03 UTC
(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".
Comment 10 Werner Donn 2006-03-02 14:09:04 UTC
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.
Comment 11 Jeremias Maerki 2006-03-02 14:27:52 UTC
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.
Comment 12 Werner Donn 2006-03-02 14:41:58 UTC
You are right. This is the best solution. Thank you very much for your efforts.
Comment 13 Yannick Majoros 2011-03-21 06:17:25 UTC
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.
Comment 14 Glenn Adams 2012-04-30 00:14:41 UTC
batch transition resolved+wontfix to closed+wontfix
Comment 15 Glenn Adams 2012-04-30 00:17:13 UTC
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