commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: [beanutils] dependencies in manifest?
Date Tue, 03 Dec 2002 15:53:23 GMT

On Tue, 3 Dec 2002, Jeff  Robertson wrote:

> Date: Tue, 3 Dec 2002 09:29:11 -0500
> From: Jeff  Robertson <>
> Reply-To: Jakarta Commons Developers List <>
> To: "''" <>,
>      "''" <>
> 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:

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:

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

View raw message