manifest classpath (was: Re: delay for release candidate)

[Christian Geisert]

Arved Sandstrom schrieb:
 Christian, if it's not already changed, this release would be a good
 opportunity to modify the manifest file Class-Path so that it does not
 expect JARs inside a lib/ directory. As was discussed some time back this is
 awkward for a number of J2EE servers. If nothing else it can lead to a
 redundancy of XML parsers and XSLT processors.
 
 Easiest way to do this and still maintain organisation is to expect fop.jar
 to be co-located with the JARs that it needs.

So just removing 'lib/' is ok ?

 Arved


Christian


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: manifest classpath (was: Re: delay for release candidate)

[Arved Sandstrom]

 -Original Message-
 From: Christian Geisert [mailto:[EMAIL PROTECTED]]
 Sent: June 10, 2002 1:20 PM
 To: [EMAIL PROTECTED]
 Subject: manifest classpath (was: Re: delay for release candidate)

 Arved Sandstrom schrieb:
  Christian, if it's not already changed, this release would be a good
  opportunity to modify the manifest file Class-Path so that it does not
  expect JARs inside a lib/ directory. As was discussed some time
 back this is
  awkward for a number of J2EE servers. If nothing else it can lead to a
  redundancy of XML parsers and XSLT processors.
 
  Easiest way to do this and still maintain organisation is to
 expect fop.jar
  to be co-located with the JARs that it needs.

 So just removing 'lib/' is ok ?

Yes, that's all that's required in the manifest.

This provides maximum flexibility. If the referenced JARs were entirely our
own it would be a different matter - we could put them where we like. But in
many deployments we ought not to constrain the locations of common JARs like
this.

Arved


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]