[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: