(detaching ant-user, where this is very OT) On Sat, Nov 17, 2001 at 01:12:10AM +1100, Peter Donald wrote: > 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.
I think we've both been barking up the wrong tree.. mostly me :P There are two documents mentioning versioning: 1) The "Optional Package" spec: The http://java.sun.com/j2se/1.4/docs/guide/extensions/versioning.html 2) The "Java Product Versioning" spec: http://java.sun.com/j2se/1.4/docs/guide/versioning/spec/VersioningSpecification.html The "Optional Package" spec suggests these manifest entries: Extension-Name: javax.help Specification-Vendor: Sun Microsystems, Inc Specification-Version: 1.0 Implementation-Vendor-Id: com.sun Implementation-Vendor: Sun Microsystems, Inc Implementation-Version: 1.0 The "Java Product Versioning" spec has these: Specification-Title: Java Utility Classes Specification-Vendor: Sun Microsystems Inc. Specification-Version: 1.3 Implementation-Title: java.util Implementation-Vendor: SunMicrosystems. Inc. Implementation-Version: build57" The difference is all in the name/title/id attributes: - The "Optional Package" spec defines how one jar can declare a dependency on another (to say "I need extension 'javax.help'"). It's "Extension-Name" attribute must be a reliable identity. - The "Java Product Versioning" spec says nothing about how to specify dependencies. Therefore the "Specification-Title" attribute is purely informational. So the questions is, do we want to: 1) "add fixed rules of interpretation" to one of these attribute sets 2) define our own attribute set and associated meanings Assuming 1), which spec? We've both been assuming the "Optional Package" spec, but I think the "Java Product Versioning" spec is more appropriate, as it is _intended_ to be general-purpose; it's just horribly under-specified :) --Jeff > 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:[EMAIL PROTECTED]] > > > 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. > > -- > Cheers, > > Pete > > ---------------------------------- > Ancient Go proverb: "Only amateurs > try to come up with 'fancy' moves" > ---------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
