Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 28010 invoked from network); 16 Nov 2001 14:15:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Nov 2001 14:15:39 -0000 Received: (qmail 29681 invoked by uid 97); 16 Nov 2001 14:15:08 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 29641 invoked by uid 97); 16 Nov 2001 14:15:07 -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 29629 invoked from network); 16 Nov 2001 14:15:06 -0000 Message-Id: <200111161415.fAGEF4203850@mail016.syd.optusnet.com.au> Content-Type: text/plain; charset="utf-8" From: Peter Donald To: "Jakarta General List" , "Danny Angus" Subject: Re: Standardized jar manifest entries? (Re: How do you version jar files?) Date: Sat, 17 Nov 2001 01:12:10 +1100 X-Mailer: KMail [version 1.3.1] Cc: "'Ant Users List'" References: In-Reply-To: X-Wisdom-Cookie: . MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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 [mailto:jeff@socialchange.net.au] > > Sent: Friday, November 16, 2001 12:36 PM > > > > > 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. > > > > > 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. -- Cheers, Pete ---------------------------------- Ancient Go proverb: "Only amateurs try to come up with 'fancy' moves" ---------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: