ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Standardized jar manifest entries? (Re: How do you version jar files?)
Date Fri, 16 Nov 2001 14:12:10 GMT
Personally I would instead choose to just enhance the jdk1.3 "Optional 
Pacakge" spec with an extra attribute. (ie Jakarta-Rules: true or something 
better named) and then just add more fixed rules on interpretation of 
versions. The reason is that the "Optional Pacakge" spec is used in servlet, 
ejb and applet containers (and webstart???) atm. It will most likely be 
incorporated into other specs as time goes on. 

It would be much less effort IMO to create a document and magic attribute 
that described meanings exactly rather than adding another cutdown version 
which is not used anywhere outside jakarta.

On Sat, 17 Nov 2001 01:01, Danny Angus wrote:
> I like this, a lot, if I had a +1 here I'd use it..
> its simple
> its addresses a real need
> it would facilitate the production of tools to deal with the nightmare that
> is .jars and the classpath
> Ant could check jars against dependencies, and build the jars from scratch
> only if need be.
> A new tool could be produced to manage the jar collections on a machine,
> (an Ant subproject?) and export the list to the classpath, only one entry
> for each package-name, and that the highest version.
> Of course that suggests there should be a fourth entry like
> Package-stability: alpha | beta | release
> so you could a) see this info, and b) decide what version should be used
> based on stability.
> d.
> > -----Original Message-----
> > From: Jeff Turner []
> > Sent: Friday, November 16, 2001 12:36 PM
> <snip>
> > 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.
> <snip>
> > 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.



Ancient Go proverb: "Only amateurs 
try to come up with 'fancy' moves"

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

View raw message