Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 94250 invoked from network); 16 Nov 2001 13:17:34 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Nov 2001 13:17:34 -0000 Received: (qmail 20699 invoked by uid 97); 16 Nov 2001 13:17:14 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 20667 invoked by uid 97); 16 Nov 2001 13:17:13 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 20655 invoked from network); 16 Nov 2001 13:17:13 -0000 Reply-To: From: "Markus Kohler" To: "'Ant Users List'" , Subject: RE: Standardized jar manifest entries? (Re: How do you version jar files?) Date: Fri, 16 Nov 2001 14:26:03 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: