Vive la Revolution! (Re: Classpath and versioned libraries for Debian-Java)

[Jeff Turner <jeff@socialchange.net.au>]

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 <opal@debian.org>
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
> 
>