On Tue, 3 Dec 2002, Jeff Robertson wrote:
> Date: Tue, 3 Dec 2002 09:29:11 -0500 > From: Jeff Robertson <[EMAIL PROTECTED]> > Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>, > "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: [beanutils] dependencies in manifest? > > BeanUtils uses both the commons logging and collections packages. However, > the Manifest in the commons-beanutil.jar makes no mention of these > dependencies. Since beanutils doesn't do this, I have to explicitly specify > collections and logging as depencies of *my* jars, even if I don't directly > use them in my own code. > > People who are just using Tomcat might be able to just throw all the jars > into WEB-INF/lib and be done with it. But when one is putting the jar files > in an EAR, for instance, the extension mechanism is very helpful. > > All I had to do was add the following line to MANIFEST.MF: > > Class-Path: commons-collections.jar commons-logging.jar > > I will submit an actual patch for it if anybody agrees that this is a good > idea. (I don't think I can even use CVS through the firewall here at work, > so I'll have to do it manually with 'diff') > > More on the java extensions mechanism: > http://java.sun.com/j2se/1.4/docs/guide/extensions/ > I agree with the concept of having commons JAR files declare their dependencies. However, declaring such JARs in a "Class-Path" header has an additional consequence -- it requires the dependent JAR files to be in the same directory as the JAR file declaring the dependency (i.e. the paths you specify are relative). In a servlet container environment, the spec (section 9.7.1) recommends that JAR files declare their dependencies according to the "Optional Package Versioning" specification: http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html which would, for commons-beanutils.jar, involve adding something like the following entry to the MANIFEST.MF file instead: Extension-List: collections logging collections-Extension-Name: org.apache.commons.collections collections-Specification-Version: 1.0 collections-Implementation-Version: 1.0 collections-Implementation-Vendor-Id: org.apache collections-Implementation-URL: ...URL to download... logging-Extension-Name: org.apache.commons.logging logging-Specification-Version: 1.0 logging-Implementation-Version: 1.0.2 logging-Implementation-Vendor-Id: org.apache logging-Implementation-URL: ...URL to download... This approach doesn't lock you into a directory structure for your class loader repository, and also lets you declare a dependency on a minimum implementation version. It would require some setup (to make download URLs available for the packages that don't have one yet), and I'm not sure that the class loader used in a standalone app actually utilizes these manifest entries. Have you (or anyone else on COMMONS-DEV) ever tried something like this? Craig McClanahan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
