Re: "scala" script and classpaths

Actually, there is already an ant task for creating runner scripts.
Here's a use of that task which sbaz uses to create its own runner
script:

  <scalascript
      file="build/toolScripts/sbaz"
      name="Scala Bazaars command-line client"
      class="sbaz.clui.CommandLine"
      version="${sbaz.version}"
      
classpath="#SCALA_HOME#/lib/sbaz.jar:#SCALA_HOME#/misc/sbaz/scala2-library.jar"
      javaFlags="-Xmx256M -Xms16M"/>



As you can see, this script is built with an explicit classpath.
Alternatively, you can leave out the "classpath" specification, and
the generated script will use every jar that is in the target
machine's sbaz/lib directory.  If you are happy with either of these
scenarios, then the current Scala toolset (in the beta) is enough.


It would be nice to take it further, though, and handle transitive
dependencies.  If there are transitive dependencies of your libraries,
it would be great to pick up on those, and it would be especially nice
if the dependency resolution happened at link time, not at compile
time.  That way, people can install new versions of libraries that
depend on other libraries.  A classic case is the compiler itself; if
you depend on scala2-library.jar right now, then you need to also link
against fjbg.jar and msil.jar.


I am familiar with the javarun script, by the way.  In fact, it was
part of the inspiration behind the way this script hackery works right
now!  The question it leaves open, though, is how the contents of the
classpath config file get created.  If I read correctly, right now
each user must set up their own file.  Maybe that's the best one can
hope for in Java-land, but I was hoping to get sbaz to the point where
you could "sbaz install eggtimer" and then have "eggtimer" as a new
command available at the shell.

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 :( , 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.

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....


-Lex