I agree with most of your ideas, but I guess it's better to separate the classpath required for the vm's, libraries and 'applications' (in the meaning of java programs with main classes). The idea is to create a dependency system for the classpaths definitions.
As an example, assume the following settings: [Kaffe classpath] /usr/share/kaffe/Klasses.jar /usr/share/kaffe/rxtx.jar [FOP (lib-fop-java) library (/usr/share/java/fop.jar) classpath] /usr/share/java/sax.jar /usr/share/java/xp.jar /usr/share/java/xt.jar [com.jtauber.fop.apps.XTCommandLine (contained in /usr/share/java/fop.jar) 'application' classpath] /usr/share/java/fop.jar The 'fop-xt' wrapper could easily discover the classpath to use with 'com.jtauber.fop.apps.XTCommandLine' by appending the [recursive] classpath required for the vm in use (or a given vm) and the [recursive] classpath required for 'com.jtauber.fop.apps.XTCommandLine'. Using this arrangement, some environment variables could be parsed by the vm wrapper: DEBIAN_CLASSPATH would refer to a 'global' classpath containing the classpaths required for the vm in use (or a given vm) and the superset of all the libraries' classpaths. DEBIAN_<PACKAGE>_CLASSPATH would refer to the classpath required by <PACKAGE> (eg. DEBIAN_LIB_FOP_JAVA_CLASSPATH, or even DEBIAN_FOP_CLASSPATH, would be translated to /usr/share/java/fop.jar:/usr/share/java/sax.jar:/usr/share/java/xp.jar:/usr/share/java/xt.jar) If this is going to be implemented, the use of /usr/share/java/repository should be deprecated (IMHO it should be deprecated anyway), particularly because it does invalidate your idea of associating priorities (as in /etc/rc.d) with classpath definitions. Julio On Sat, Nov 06, 1999 at 06:14:24PM -0600, Ean R . Schuessler wrote: > I have been giving a lot of thought to the policy that Stephane has > proposed. While I certainly appreciate the sentiment that has caused > him to push for adoption so strongly I still am not wholly satisfied > with the direction of his efforts. > > I do understand that Debian policy discourages the concept of a > program requiring that an environment variable be set in order to > operate sanely. Unfortunatly, one of the key design decisions in the > Java language is this notion of class repositories that are defined > through the CLASSPATH environment variable. Stephane's solution has > been to essentially disable the use of this feature within the Debian > system. This has some disadvantages that I find difficult to accept: > > - Users cannot easily pick and choose which sets of classes they would > like to use out of a group of installed java class sets. The only > way that they can do this is to download the jars from a seperate > site and put them into their classpath. > > ie. CLASSPATH=/home/ean/jars/jigsaw.jar:/usr/share/java/repository > > This defeats the basic purpose of the dpkg/apt system (installing > packages) and in that sense defeats the purpose of Debian. > > - It is not possible to install multiple implementations of the same > class domain with the repository scheme. If you have a GTK > implmentation of the AWT and a Xlib implementation they will both > include java.awt.* classes and must therefore conflict. This is > what the jar mechanism works to allow and is too important a > feature to remove. > > I understand the motivation to establish the scheme that Stephane has > selected because it provides an obvious and immediate solution to the > problem of transparently activating new java classes when installed. > I contemplated this same scheme some time ago but discarded it when > most of the issues above were posed to me. There are alternatives to > this scheme, however, that offer similar utility and do not suffer > from the encumberances of Stephane's outlined method. > > The best advice is perhaps to follow what policy actually states as > the technique for dealing with programs that require an environment > setting, a wrapper script. It is fairly trivial (1 line of shell code) > to read in a list of configured classpaths from a folder in /etc and > use these to build a classpath for the VM being spawned. > > Adam Heath and I have been discussing an arrangement where each > package of classes would place a file marked as a configuration file > into some central directory, say, /etc/classpaths. Each of these > configuration files would contain a list of class locations as below: > > [file /etc/classpaths/00kaffe.classes] > /usr/share/kaffe/Klasses.jar > /usr/share/kaffe/microsoft.jar > /usr/share/kaffe/rxtx.jar > > These files would be aggregated to form a final classpath that the VM, > or other program, would use. This can be done easily in a single line > of shell code and even provide a notion of comments and priority. This > way you can do something like... > > [file /etc/classpaths/00kaffe.classes] > /usr/share/kaffe/Klasses.jar > #/usr/share/kaffe/microsoft.jar > /usr/share/kaffe/rxtx.jar > > with an ease that is not possible under Stephane's proposed system. > The notion of priority, ala rc.d, is also interesting. You might see > the contents of /etc/classpaths looking something like: > > 00kaffe.classes > 10classpath-servlet.classes > 11sun-servlet.classes > > Or some system that allows the order of inclusion in the CLASSPATH to > be built easily. Also, it would probably be nice to have a notion of a > symbol that represents the dynamically constructed CLASSPATH portion. > A symbol such as DEBIAN_CLASSES could be used. This way, if you set > your CLASSPATH to: > > CLASSPATH=/home/ean/jars/myevilstuff.jar:DEBIAN_CLASSES > > The shell script would do the proper expansion when calling the VM. > This would allow you to customize the classpath and still get the > benefits of dynamic jar inclusion. > > I know that it is a bit late in the game to get this concept into > freeze but I don't think it is that big a stretch to get it put > together this weekend. I am considering putting it into the kaffe > package in some form whether it is adopted on a wider basis or not. > I frankly don't intend to follow the current Java policy as it stands > because I simply don't think that it is the right way to solve the > problem. I hope that it is understood that my motivation for taking > that stance is purely one of design principal and not a desire to > simply be mean. > > If this idea is recieved favorably perhaps it and some other > formalizations can be folded into some final and genuine java policy. > > E > > -- > ___________________________________________________________________ > Ean Schuessler An oderless programmer work-a-like > Novare International Inc. Silent and motionless > *** WARNING: This signature may contain jokes. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
