Re: RFC: An alternative to /usr/share/java/repository
Comments:
1) The global CLASSPATH environmental variable never worked for me. I have too
many different versions of JVMs (blackdown, ibm, kaffe, 1.1, 1.2) that
I generally always set up an application-specific classpath within an
application-specific invocation script.
2) Even application-specific classpaths my not have fine enough granulatity.
For example, if I have a java database applications, it may be capable of
accessing several different databases, such as mysql, oracle, sybase, etc. It
would not be until application configuration time (if not *invocation* time)
that a particular java driver needs to be identified and somehow added to the
classpath.
3) I like the rc.d-style approach. However, we may want to add further
sub-classifications:
* which classpath elements belong to a particular JVM (blackdown vs ibm)
* which classpath elements are dynamically loaded (e.g., database
drivers)
Chris
"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: