xmlgraphics-fop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 38821] - The manifest file no longer has a Class-Path entry
Date Wed, 01 Mar 2006 19:23:18 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38821>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38821





------- Additional Comments From werner.donne@re.be  2006-03-01 20:23 -------
> > 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.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Mime
View raw message