On Fri, Sep 14, 2001 at 04:45:42PM -0500, Ben Burton wrote: > > Just a couple of notes; I'll think about this over the weekend too.
> The first thing I should say is that this registry is *not* primarily > intended for end users; it's mostly provided to aid startup scripts for > other packages; to allow them to be friendlier and to break under fewer > system configurations. That sounds good. I think I'm a bit more on the end-user-side but still on the side end-developer-side. :) > > > - A Java app may need runtime version >= foo but currently has no way of > > > knowing if such a runtime is installed, or even if it is then whether > > > /usr/bin/java points to such a runtime, and if not then where to find > > > such a runtime (note that the output of java --version is not > > > consistent across JVMs). > > > > That is true. Is there a way to "Depend: java-virtual-machine (>= 1.3)" ? > > Not right now, but even if it were possible, there's no guarantee that > /usr/bin/java points to the 1.3 JVM as opposed to some other 1.1 JVM. > Using package dependencies is not enough here; hence the proposed registry > with a script to launch a JVM of version >= foo. Maybe we should force the existance of a java-1.3 symlink in the bin dir? Don't get me wrong. I just want to have a simpler somlution than a registry, but still more general. > > > - Another app may need to know where the core Java classes are. There is > > > currently no way for anyone to know this other than to have a > > > hard-coded list of classpaths for each JVM available for debian (this > > > is what the whichjava script tried to address, but I want to replace > > > that with this new proposal). An example here is jikes which needs to > > > be given the bootstrap classpath from another installed JVM. > > > > But acording to the policy the binary that sets up the virtual machine must > > give the correct classpath for its environment. > > I'm not talking binaries that start Java apps; I'm talking binaries that > refer to core Java classes for other reasons, such as Jikes (which refers > to them during compilation). Ok. I see. > > > - A Java app may for whatever reason need to know which particular JVM is > > > being called by (say) /usr/bin/java. An example here is jython which > > > doesn't work with ORP; rather than spew out indecipherable error > > > messages, one wants the startup script for jython to detect that orp is > > > being used and display a polite message explaining the problem and > > > advising how to request a different JVM. > > > > Is juthon a command line tool? If so it should provide a command line tool > > that have the correct init lines. But maybe I'm starting to get the point. > > You want to create a registry to help the program to get information about > > what is installed. > > Yep, you're right. Jython is a command-line tool, and the registry would > be queried by the jython startup script itself so it can behave properly > from the viewpoint of the end user. > > > But to me it still looks like you want to propose some virtual packages. I was not really clear on this point. I ment that you were proposing the mechanism similar to propose some virtual packages. > The only virtual packages I have proposed were java2-*, which were on a > different thread. The Package: field in the registry file would refer > to the actual debian package that contains the JVM/compiler. > > > Yes but the main problem is that some of the virtual machines just > > do not provide everything and so in some cases you have to add extra > > things to the classpath. Swing for example is provided by j2sdk1.3 but > > have to be added manually for all other jvm:s. > > So once again the registry is your friend. Your swing-app startup script > queries it to see if the JVM it's calling is 1.3 or less; if it's less, it > addes the swing classes to the classpath and if not it doesn't. The > registry actively helps get around this problem. Now I can see the difference in out viewpoint. You have good knowledge in what classes that are provided by each virtual machine. I do not have that knowledge (or at least not that good), so I have to look it up from time to time. What I want is a mechanism so that I do not need that knowledge. :) > > There are still some issues that are insane... All the java libraries > > provided > > by different packages, like xalan, bsf, fop, xerces, xt and more. If you > > are about to use them you have to manually include them. > > The way I've got jython working is this: The jython startup script takes > everything the user wants on the classpath from $CLASSPATH. To that it > adds the libraries jython requires (such as servlet-2.2.jar). This > larger $CLASSPATH is passed to the JVM, which in turn should add its own > bootstrap classes. Thus everything works. If you want more details, try > installing the jython package and look at /usr/bin/jython (ignore the use > of whichjava; this is what the registry would hopefully replace). That sounds like the perfect way of doing this. As I understand it there are some problems. 1) You do not know if you got the right jvm. 2) The jvm does not always add the right CLASSPATH for itself. That is a bug though. 3) Even if you include the jars that you know, they can depend on other jars that you have to find out (can be quite hard). 4) More? > The point being that the packager of an individual Java app should know > what dependencies that app has, can put them in the debian Depends: and > include them on the classpath in the app's startup script, as described > above. Exactly. > > There can also > > be version conflicts... And the thoughest thing is that you do not just > > have to know what it depends on, you also have to know what jvm:s that > > package > > depends on, and so on. > [...] > > So I want to generalize your repository (or what you want to call it) to > > include all packages that provides or depends on some sort of jar files. > > What's wrong with using debian depends for this? As far as individual > (non-core) libraries go you can get away without virtual packages; eg: > > Depends: libservlet2.2-java (>= foo), lib-editline-java (>= bar) Nothing. That is a perfect way of doing it. The thing is that I want to use that information to set the correct classpath. :) > Perhaps I'm missing something here; could you please give a (hypothetical > is okay) example of how using debian depends would fail? Well they do not fail, but they are not enough to set the correct classpath. :( Take this example (hypothetical) that I have faced sometimes with the java library (and servlet) packages that I maintain. We have four packages. Package: foo Type: servlet, library or command-line tool. Depends: bar Package: bar Type: library package only Depends: gaz (always) Package: gaz Type: library package only Depends: goo (sometimes in some special cases) Package: goo Type: library package only So we want to set the correct classpath for foo. In the documentation for foo we can see that it depends on bar. Bar is packaged in a special way, normally the jar file also contains gaz, but becuase of some issues (like dependency problems or other) it has been split into two archives. So the maintainer adds bar.jar into the classpath. He (or she) test it and finds out that ... ohh gaz.jar should be added too. This is what I want to avoid. Ok it works but we can have one more case (not as obvious). We now have CLASSPATH=bar.jar:gaz.jar But in some rare cases that foo triggers in some important function that foo needs. Because foo does not depend on goo (to compile, but to run in some cases) directly it can be very difficult for the user or maintainer to find it out. So we are talking about different things I think. You are focused on the virtual machine and I focus on the packages (on a quite high level) that depends on a LOT other jar archives. There are a number of ways to fix this but this is On compile time a script can be generated for each jar-archive that provides a proper classpath on the information it gets from the "Depends:"-line. * Problems: - One package can provide a number of jar archives (which can conflict with each other). Xalan2 is a example of this. It provides both xalan1 and xalan2 compatible jars, even if the xalan1 one is not always perfectly backwards compatible. - If the dependency information ("below" the package) changes the package have to be recompiled. So you have to have a tool that gets this information on run-time. * Sultion: + As I proposed on some other message each java-library package should "Provide:" all jars it contains. So you only have to depend on the jar file name. + Have a tool that fixes this information on run-time and not on compile time. > The big difference I see is that the core classes come from virtual > packages java-virtual-machine, etc. and are not provided in any standard > sort of location, whereas 3rd party libraries come from real packages and > are provided in /usr/share/java/package-name.jar. Maybe we should have a standard location for them. :) Symlinks are just fine to me. > Hmm, I'll think some more. Me too. :) What I can see we have two major problems: 1) Tools that needs to have a bootstrap classpath, like jikes. 2) The problem of jars that depends on other jars that are not obvious on compile-time. I want to have a (or maybe two but not too different) mechanism that fixes both issues. I'll think some more. But it should be solvable if we just standardize it some (and get rid of that damn /usr/share/java/repository directory). :) Regards, // Ola -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Björnkärrsgatan 5 A.11 \ | [EMAIL PROTECTED] 584 36 LINKÖPING | | +46 (0)13-17 69 83 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---------------------------------------------------------------