ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Kohler" <koh...@cms.tecmath.de>
Subject RE: Standardized jar manifest entries? (Re: How do you version jar files?)
Date Fri, 16 Nov 2001 13:26:03 GMT
Yes Yes Yes,

This is almost exactly what I wanted to implement anyway :-)
Another application for example is that you can print out the versions of
all jar-files
within your classpath. I've already done that.


Regards,
Markus

> -----Original Message-----
> From: Jeff Turner [mailto:jeff@socialchange.net.au]
> Sent: Friday, November 16, 2001 1:36 PM
> To: general@jakarta.apache.org
> Cc: 'Ant Users List'
 [snip]
> > 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.
>
>
> --Jeff
>
>
> [1] http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html
>
> [..]
> >
> > Markus
>
> --
> To unsubscribe, e-mail:
<mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message