Re: RFC: An alternative to /usr/share/java/repository
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 debian-java-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
Reply to: