Re: "scala" script and classpaths

On Tue, Feb 07, 2006 at 12:29:20PM +0100, Lex Spoon wrote:
> The best design I see so far seems to be to have a custom dependency
> entries in the jar files (or possibly elsewhere in the sbaz
> directory), and then to write a little runner analogous to
> /lib/ld-linux which processes all the dependency information to figure
> out what classpath to use.  The main questions remaining are then what
> kind of dependency information exists (depends-on, provides,
> versions?), and where all this information is stored (sbaz jars,
> external jars, environment variables, config files...).  It is easy to
> get carried away :( ,

As it happens, I am just now having to address this same problem for
the next version of Kitten (it's morphed into a more general component
container, and the components have to interact).

At present, I'm thinking that there are two types of dependencies,
which I'll call internal and external: internal dependencies do not
define classes that are part of the exposed API of the depending
package, whereas external ones do.

The difference is important where there are multiple incompatible
versions of a package in use by different components (depressingly
common: Log4j is a prime example). If the dependency is internal, we
can load the different versions in different classloaders and they can
happily coexist. If the dependencies are external, we need to maintain
class identities and thus only one copy of the dependency can be
loaded. Two packages which externally depend on different versions of
the same package are incompatible and cannot coexist inside a
classloader (but it's okay if they are themselves internal
dependencies of different packages...).

> but hopefully there is a reasonably small set of
> features in there which will get library dependencies working as
> nicely as they do in Debian and other Linux distros.

Linux distributions have the advantage that they always deal with
source code, tweaked as necessary, either directly as in Gentoo, or
packaged by a centralised group as in Debian, and they have a notion
of a version for the whole distribution. They typically disallow
library version conflicts and settle upon some 'latest' version of
each package, which all other packages must conform to.

Since the Java world seems to insist that Java binaries are portable,
despite all the evidence to the contrary, and since AIUI sbaz is
intended to be much more distributed than a Linux distribution, I
think things get a little more tricky...

> A side benefit would be that if you have a big /usr/share/java
> directory full of libraries from a 3rd party, then you could link
> against those even though (a) they aren't managed by sbaz and (b) they
> might be in a different location on each person's machine.  The
> approach would be to have a ld.path file somewhere that lists all
> directories to scan for jars....

That's what we were hoping for with Javarun, but because jars aren't
properly versioned, we found that in practice we had to explicitly
specify the dependencies in a per-program configuration file. I think
this at least means forcing all jars to have canonical
'package-version.jar' names.

I think this is what you're getting at with your 'package universes'
business, which I have to say I'm a little sceptical about (it may
make life easier for the developer, but what about the user?)

Ok, I'll stop there. This is a can of worms indeed... I hope some of
it makes sense and is at least vaguely relevant.

-- Jamie Webb