ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Standardized jar manifest entries? (Re: How do you version jar files?)
Date Fri, 16 Nov 2001 12:35:56 GMT
(was getting off-topic for ant-user)

On Fri, Nov 16, 2001 at 09:36:24AM +0100, Markus Kohler wrote:
> Hi, 
> > -----Original Message-----
> > From: Peter Donald []
> > Sent: Friday, November 16, 2001 12:19 AM
> > To: Ant Users List
> > Subject: Re: How do you version jar files?
> > 
> > 
> > On Fri, 16 Nov 2001 09:47, Conor MacNeill wrote:
> > > Scott,
> > >
> > > There are a number of ways to version jars depending on your taste.
> > > 4. Add a manifest entry to the jar.

> If Java would have a standard for this  (I haven't found one) it would
> be really cool to support this with an Ant Task.

Java's official versioning spec [1] seems curiously irrelevant. It talks
about API specifications, and implementations thereof; not the sort of
scenario most people deal with. It's primary use-case seems to be
applets (it amuses me how Sun documents can be dated this way;)

So how about defining a Jakarta-wide standard subset of jar manifest
entries?  Something very simple, eg:

Package-name: xalan
Package-version: 2.2
Package-depends: xerces, 1.4.3

Then write a standard Java tool that can query any conforming jar, and
print this info. The dependency information would allow the tool to
recursively trace down dependencies, and print a complete list.

Btw, note the difference between "Class-Path:" and "Package-depends:".
One specifies physical jar names (a brittle, error-prone solution), and
the other specifies logical, abstract dependencies. This "abstractness"
would allow jar taxonomies to be defined; eg:

Package-depends: jaxp-parser, 1,1

would be satisfied by any JAXP 1.1-compatible parser.

Then one could have an abstract-to-physical-dependency mapping tool, to
translate "xerces, 1.4.3" to wherever you keep your 1.4.3 xerces.jar. An
init script or custom ClassLoader could then make use of this info, so
you'd no longer need 15 xerces.jar files on your harddisk :)

alexandria-dev folks (JvZ, SamR, Geir,..): think of this as proposing a
"guaranteed substratum" of jar metadata, which Gump, JJAR etc can use.

Does that sound workable? Don't be distracted by talk of taxonomies and
classloaders.. those are just applications. All I'm proposing right now
is 3 standardized manifest entries, and a tool to read them. That alone,
if adopted widely, would be of great benefit in a world of proliferating
unidentifiable jars.



> Markus

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message