Bug 38821

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