On Fri, Nov 09, 2001 at 10:51:01AM +0100, Max Kellermann wrote: [..] > > At first, we need a library database (applications will be put there, > too). Maybe just a path containing a description file for every > library, whatever you may call database. Every Java library and every > Java application installs its description (maybe XML, maybe Debian > control file format, I don't care at this time). The description > contains a list of all .JAR files with its full path (although we may > specify that all libraries will be installed in /usr/share/java). > > For every .JAR file, it contains a list of something like 'virtual > packages' - sub-libraries, provides lines, whatever we may call them; > with version numbers of course. Xerces-1.4.3.jar contains Xerces > (1.4.3), DOM Level 2 (1.0), SAX 2. Xalan-2.1.0.jar contains Xalan2 > (2.1.0), TRAX (1.0). Every .JAR file also describes which > 'sub-libraries' it requires.
Hi Max, I like those ideas.. they got me thinking. Let me sketch a proposed revolution :) How about using the jar manifest to store the jar metadata, as Sun intended? Make the jars their own database. A platform-independent database :) Eg, for Xalan.. Package-name: xalan Package-description: An XSLT processor from Apache Package-url: http://xml.apache.org/xalan-j/ Package-version: 2.2 Package-depends: xerces, 1.4.3 Package-depends: bsf, 1.0 Notice that that's all OS-independent info that the Xalan people can maintain directly. Then have separate, Operating-system-specific "physical" metadata. Basically a subset of what dpkg stores currently (minus the logical info above): Package-name: xalan (the "foreign key") Package: libxalan-java Maintainer: Ola Lundqvist <[EMAIL PROTECTED]> Filename: /usr/share/java/libxalan-1.4.3-2.jar State: installed Then we write an extension of dpkg which 'merges' the logical and physical metadata, to obtain full dpkg-like functionality. More than just dpkg functionality, actually.. eg, we could deduce the physical classpath for running xalan programs, by first finding all logical dependencies, and then looking up their physical mappings. Now isn't that more sensible that the manifest's existing 'Class-Path:' system? Nobody uses it much, because it specifies physical information (relative filenames) that a simple file rename can break, whereas it *should* be specifying logical info (abstract dependencies) that gets "resolved" into physical info. So what else does this logical/physical separation buy us? Well it's 2am, so I won't go into it deeply.. but here are some benefits, derived from wider ownership of "logical" metadata: - It delegates maintenance of some metadata to the upstream source. Most importantly, dependencies. See Adam Heath's rant in a separate thread, and think of how this could solve the problem.. ;) - It makes an important subset of a package manager's functionality available in an OS-independent way. Not everyone needs full package management. One could to go any jar on *any* system, poke it, and get back it's logical info (eg 'dpkg --status'), including dependencies. Light-years away from today's situation, where it's usually impossible for a sysadmin (non-programmer) to determine a jar's version and dependencies. - It allows for logical hierarchies. Jar taxonomies (expressing relationships). Semantic equivalence. Expressing that "Saxon does the same thing as Xalan". All cross-platform. Very cool possibilities.. So to summarise, I'd like to: - separate out logical info, and let upstream maintain it. - build as much system-independent functionality on that logical info as possible. - add OS-specific physical info, which can be used in conjunction with the logical info (like a db 'join') to provide a full package management system like dpkg. Does this make sense? I hope so.. I think could be very cool :) Success requires *simplicity*, and there's not much simpler than adding a few standardized fields to a manifest. Why would people bother? Because they'd then be able to use standardized Java tools that meet a real need: basic platform-independent jar identification and management. Once a certain critical mass is achieved, then things get really exciting, with online jar catalogs, ontologies, etc. Ideally, the system could be submitted as a JSR, and the common tools become part of the JDK. Or maybe not.. I may regret sending this in the morning ;P I'd appreciate any thoughts on this. --Jeff [..] > Regards, > Max > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
