> *And now some stuff about servlet engines
> This gets more complicated when you consider servlet engines. Servlet
> engines should have their code (jars or classes) specified on the
> classpath (ie: 3).
>
> The classes and jar files that define applications (eg: servlets and
> so forth) go in an
It seems to me this discussion would benefit from a re-statement of
the class loading ground rules (as specified by Sun).
There are 3 places that a Java class can be loaded from:
1. the boot-classpath
used only for core java.* classes (and the CORBA stuff and anything
else Sun or other JVM mainta
> * Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Isn't that what the Debian package "conflicts" and "requires" settings
are
> > for? If I compile Apache against libc5 and then replace libc5 with
libc6,
> > Apache's going to break until I recompile, right? However, the Debian
> > packaging
* Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Ah, wouldn't that be nice. If every package maintained compatibility
> > release to release, we could do that. But that doesn't always happen.
> > For example, Kawa's package hierarchy is going through some
> > reorganization, such that if I
> *And now some stuff about servlet engines
> This gets more complicated when you consider servlet engines. Servlet
> engines should have their code (jars or classes) specified on the
> classpath (ie: 3).
>
> The classes and jar files that define applications (eg: servlets and
> so forth) go in a
> Ah, wouldn't that be nice. If every package maintained compatibility
> release to release, we could do that. But that doesn't always happen.
> For example, Kawa's package hierarchy is going through some
> reorganization, such that if I compile BRL against Kawa 1.6.67 won't
> work with Kawa 1.6.
It seems to me this discussion would benefit from a re-statement of
the class loading ground rules (as specified by Sun).
There are 3 places that a Java class can be loaded from:
1. the boot-classpath
used only for core java.* classes (and the CORBA stuff and anything
else Sun or other JVM maint
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
> general I would prefer a strictly extension dir
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
> Good point. The current method of debanizing jars is going to fail
> soon, since most I've run into don't version stamp the filename.
Not really. If a given debianized jar needed to support multiple versions, it
could be modified
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
>
> Joe Emenaker sent a nice idea to me which the list didn't get to
> see. He suggested making a script which does autodetection of jar
> files in your /usr/share/java and sets the classpath
> appropriately. Though I don't think tha
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack on new jar
> file to the classpath every tim
Depending on which Kaffe you are using this is probably largely my fault.
There are a number of features (including even X AWT GUI support) that are
silently disabled during the Kaffe build if you do not have the proper header
files installed. One of these things is BigInteger and other arbitrary
> "Per" == per <[EMAIL PROTECTED]> writes:
Per> Juergen Kreileder <[EMAIL PROTECTED]> writes:
>> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
>> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
>> install into those directories.
> * Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Isn't that what the Debian package "conflicts" and "requires" settings
are
> > for? If I compile Apache against libc5 and then replace libc5 with
libc6,
> > Apache's going to break until I recompile, right? However, the Debian
> > packaging
On Wed, Nov 08, 2000 at 12:58:31PM -0800, Aaron Brashears wrote:
> I think that only has to do with standard extensions to java, such as
> java3d or java media framework. I've been using blackdown's 1.3 jdk
> from debs recently, and the script appear to do autodetection of jars,
> but does set the
> "Per" == per <[EMAIL PROTECTED]> writes:
Per> Aaron Brashears <[EMAIL PROTECTED]> writes:
>> Joe Emenaker sent a nice idea to me which the list didn't get to
>> see. He suggested making a script which does autodetection of jar
>> files in your /usr/share/java and sets the cl
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
>
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> I need some advice on setting up a working java 1.2
Manoj> environment on Debian: is there such a beast?
Our 1.3 and some additional packages are available as deb packages
from our mirrors:
http://www.blackdown.org/java-
On Wed, Nov 08, 2000 at 12:22:39PM -0800, [EMAIL PROTECTED] wrote:
> Aaron Brashears <[EMAIL PROTECTED]> writes:
>
> > Joe Emenaker sent a nice idea to me which the list didn't get to
> > see. He suggested making a script which does autodetection of jar
> > files in your /usr/share/java and sets t
* Joe Emenaker <[EMAIL PROTECTED]> [001108 14:04]:
> > Ah, wouldn't that be nice. If every package maintained compatibility
> > release to release, we could do that. But that doesn't always happen.
> > For example, Kawa's package hierarchy is going through some
> > reorganization, such that if I
Aaron Brashears <[EMAIL PROTECTED]> writes:
> Joe Emenaker sent a nice idea to me which the list didn't get to
> see. He suggested making a script which does autodetection of jar
> files in your /usr/share/java and sets the classpath
> appropriately.
Which is what you have to do anyway if you wan
Hi,
I need some advice on setting up a working java 1.2
environment on Debian: is there such a beast? I know I may have to
use non free stuff to make it happen.
I am trying to use ARGO UML, which happens to be DFSG fee, but
needs java 1.2 to work.
I have downloaded j
On Wed, Nov 08, 2000 at 09:49:47AM -0500, [EMAIL PROTECTED] wrote:
> Aaron Brashears <[EMAIL PROTECTED]> writes:
>
> > After some reflection it seems that it would make more sense to just
> > copy the class files in /usr/share/java so setting the classpath for
> > standard packages would be handle
> Ah, wouldn't that be nice. If every package maintained compatibility
> release to release, we could do that. But that doesn't always happen.
> For example, Kawa's package hierarchy is going through some
> reorganization, such that if I compile BRL against Kawa 1.6.67 won't
> work with Kawa 1.6
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
> general I would prefer a strictly extension di
On Wed, Nov 08, 2000 at 04:05:04AM -0300, Nicolás Lichtmaier wrote:
> The truth is that there isn't a Java policy.
True, but there is a proposed java policy, which seems like a good
starting point. AFAIK, most java packages for debian are conforming to
the java policy.
apt-get install java-commo
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
> Good point. The current method of debanizing jars is going to fail
> soon, since most I've run into don't version stamp the filename.
Not really. If a given debianized jar needed to support multiple versions, it
could be modifie
On Wed, Nov 08, 2000 at 12:03:40PM -0800, Aaron Brashears wrote:
>
> Joe Emenaker sent a nice idea to me which the list didn't get to
> see. He suggested making a script which does autodetection of jar
> files in your /usr/share/java and sets the classpath
> appropriately. Though I don't think th
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack on new jar
> file to the classpath every ti
Depending on which Kaffe you are using this is probably largely my fault.
There are a number of features (including even X AWT GUI support) that are
silently disabled during the Kaffe build if you do not have the proper header
files installed. One of these things is BigInteger and other arbitrary
> "Per" == per <[EMAIL PROTECTED]> writes:
Per> Juergen Kreileder <[EMAIL PROTECTED]> writes:
>> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
>> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
>> install into those directories.
On Wed, Nov 08, 2000 at 12:58:31PM -0800, Aaron Brashears wrote:
> I think that only has to do with standard extensions to java, such as
> java3d or java media framework. I've been using blackdown's 1.3 jdk
> from debs recently, and the script appear to do autodetection of jars,
> but does set the
Juergen Kreileder <[EMAIL PROTECTED]> writes:
> Our Java 2 packages use a extension directory /usr/lib/j2re1.3/ext (and
> /usr/lib/j2re1.3/$(ARCH)/lib). The packages for Java3D, JAI and JMF
> install into those directories.
>
> Additionally we add /usr/share/java/repository to CLASSPATH but in
> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:
Manoj> I need some advice on setting up a working java 1.2
Manoj> environment on Debian: is there such a beast?
Our 1.3 and some additional packages are available as deb packages
from our mirrors:
http://www.blackdown.org/java
On Wed, Nov 08, 2000 at 12:22:39PM -0800, [EMAIL PROTECTED] wrote:
> Aaron Brashears <[EMAIL PROTECTED]> writes:
>
> > Joe Emenaker sent a nice idea to me which the list didn't get to
> > see. He suggested making a script which does autodetection of jar
> > files in your /usr/share/java and sets
> "Per" == per <[EMAIL PROTECTED]> writes:
Per> Aaron Brashears <[EMAIL PROTECTED]> writes:
>> Joe Emenaker sent a nice idea to me which the list didn't get to
>> see. He suggested making a script which does autodetection of jar
>> files in your /usr/share/java and sets the c
Aaron Brashears <[EMAIL PROTECTED]> writes:
> Joe Emenaker sent a nice idea to me which the list didn't get to
> see. He suggested making a script which does autodetection of jar
> files in your /usr/share/java and sets the classpath
> appropriately.
Which is what you have to do anyway if you wa
Hi,
I need some advice on setting up a working java 1.2
environment on Debian: is there such a beast? I know I may have to
use non free stuff to make it happen.
I am trying to use ARGO UML, which happens to be DFSG fee, but
needs java 1.2 to work.
I have downloaded
On Wed, Nov 08, 2000 at 09:49:47AM -0500, [EMAIL PROTECTED] wrote:
> Aaron Brashears <[EMAIL PROTECTED]> writes:
>
> > After some reflection it seems that it would make more sense to just
> > copy the class files in /usr/share/java so setting the classpath for
> > standard packages would be handl
On Wed, Nov 08, 2000 at 04:05:04AM -0300, Nicolás Lichtmaier wrote:
> The truth is that there isn't a Java policy.
True, but there is a proposed java policy, which seems like a good
starting point. AFAIK, most java packages for debian are conforming to
the java policy.
apt-get install java-comm
Aaron Brashears <[EMAIL PROTECTED]> writes:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack
Aaron Brashears <[EMAIL PROTECTED]> writes:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> CLASSPATH=/usr/share/java once instead of having to tack
On Tuesday 7 November 2000, at 21 h 55,
the keyboard of Aaron Brashears <[EMAIL PROTECTED]> wrote:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
> C
> I've been thinking about the way debian java packages are built. For
> example, libxerces-java and ant are both distributed as jar files
> which wind up in /usr/share/java and some documentation which goes in
> /usr/share/doc/. According to the java policy, debian
> java packages can be distribut
On Tuesday 7 November 2000, at 21 h 55,
the keyboard of Aaron Brashears <[EMAIL PROTECTED]> wrote:
> After some reflection it seems that it would make more sense to just
> copy the class files in /usr/share/java so setting the classpath for
> standard packages would be handled once by setting
>
45 matches
Mail list logo
