xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajiv Mordani [CONTRACTOR]" <Rajiv.Mord...@eng.sun.com>
Subject Re: [Proposal] Guidlines for package distribution of Java projects:like XML file being read by class
Date Thu, 25 Nov 1999 00:17:34 GMT
The URL should be 

>Mailing-List: contact general-help@xml.apache.org; run by ezmlm
>X-No-Archive: yes
>list-help: <mailto:general-help@xml.apache.org>
>list-unsubscribe: <mailto:general-unsubscribe@xml.apache.org>
>list-post: <mailto:general@xml.apache.org>
>Delivered-To: mailing list general@xml.apache.org
>Date: Wed, 24 Nov 1999 16:21:19 -0800
>From: James Duncan Davidson <james.davidson@eng.sun.com>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: general@xml.apache.org
>Subject: Re: [Proposal] Guidlines for package distribution of Java 
projects:like  XML file being read by class
>Content-Transfer-Encoding: 7bit
>Mike Pogue wrote:
>> I think we really need both ways:
>> a) at runtime, there must be a way to query the version string, AND
>Suggestion for this (at least for the Java side):
>	1) Use the version info in the manifest.mf format
>	2) Have a Version.java in the base package that would
>		a) on 1.2+ use java.lang.Package
>		b) on 1.1 getResource("META-INF/manfiest.mf") and parse
>For those that aren't "up" on the 1.2 package versioning spec, look at:
>More explicitly, here's a sample manifest that shows the kind of version
>information that is exposed:
>	  Manifest-version: 1.0
>          Name: java/util/
>          Specification-Title: Java Utility Classes 
>          Specification-Version: 1.2
>          Specification-Vendor: Sun Microsystems Inc. 
>          Implementation-Title: java.util
>          Implementation-Version: build57 
>          Implementation-Vendor: SunMicrosystems. Inc.
>> b) at install time, it's nice to be able to look at a JAR, and determine
>> what version it is, without running a program.
>Yep. The files can be named xerces-1.0.1.jar etc. Hmmm. Maybe in Ant
>there can be an option to auto version the generated file based on the
>manifest. I'll take a look at that tonight as that might be pretty cool
>irregardless of this discussion.
>On my system, use I keep a lot of utility jars around with just this
>kind of format and just shift my classpath accordingly. Now that the new
>JDK load all jars in the /lib/ext directory, I just use that and keep a
>backlog of older jars.
>James Davidson                                     duncan@eng.sun.com 
>Java + XML / Portable Code + Portable Data                 !try; do()

View raw message