Bug#348649: ftbfs: I can't find file `policy.aux'.

2006-01-18 Thread Max Kellermann
Package: java-common Version: 0.23 Tags: FTBFS Severity: minor This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5) entering extended mode (/opt/debian/build/java-common-0.23/policy.tex JadeTeX 2003/04/27: 3.13 (/usr/share/texmf/tex/latex/psnfss/t1ptm.fd) Elements will be labelled ! LaTeX Error:

Re: Tomcat 3.3 / 4.0 ? When?

2001-12-01 Thread Max Kellermann
On 2001/11/30 22:28 Adam == Adam Heath [EMAIL PROTECTED] writes: Stefan == Stefan Gybas wrote: Stefan Fine, and the Debian package uses the same user as Apache Stefan (default: www-data), also for security reasons :) Adam I consider that a bug, and should probably file one. tomcat

Re: Tomcat 3.3 / 4.0 ? When?

2001-12-01 Thread Max Kellermann
On 2001/11/30 22:28 Adam == Adam Heath [EMAIL PROTECTED] writes: Stefan == Stefan Gybas wrote: Stefan Fine, and the Debian package uses the same user as Apache Stefan (default: www-data), also for security reasons :) Adam I consider that a bug, and should probably file one. tomcat Adam

Re: [summary] Re: policy proposition for javadoc installation

2001-11-27 Thread Max Kellermann
On 2001/11/26 18:55 I agree that if there is a package with so much documentation that installing it all might take up too much space. In that case, separate -doc and -javadoc packages would be ok. But Debian tends to discourage frivilous package splitting, so this should only be done as

Re: Java Classpath builder

2001-11-24 Thread Max Kellermann
Debian package. Regards, Max Kellermann -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Java Classpath builder

2001-11-24 Thread Max Kellermann
Debian package. Regards, Max Kellermann

Java Classpath builder

2001-11-14 Thread Max Kellermann
Hi, I have made a Debian package containing an experimental java classpath builder (I have posted a large email about that topic last week). It does not yet resolve complex dependencies, it's just a point to start at, to give you an impression of what I'm planning for debian-java. If you want

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Per Bothner [EMAIL PROTECTED] wrote: The most glaring missing feature in gcj is AWT. If you're running server-style or other non-GUI application, I suggest you try it. See htpp://gcc.gnu.org/java/ Has anybody tried running Tomcat with gcj? Tomcat should be THE Java server.. if

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Tom Tromey [EMAIL PROTECTED] wrote: Max == Max Kellermann [EMAIL PROTECTED] writes: Max Does gcj support loading new .JAR files dynamically at run-time Max like with its .WAR files at all (i.e. creating custom ClassLoader Max implementations)? I can hardly imagine how it implements

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Alexandre Petit-Bianco [EMAIL PROTECTED] wrote: RHUG's jython relies on that feature to work: jython spits bytecode out of Python files and then interprets them. It is our intent to insert an optional compilation stage. libgcj could then load a shared object instead of a bytecode file.

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Per Bothner [EMAIL PROTECTED] wrote: The most glaring missing feature in gcj is AWT. If you're running server-style or other non-GUI application, I suggest you try it. See htpp://gcc.gnu.org/java/ Has anybody tried running Tomcat with gcj? Tomcat should be THE Java server.. if

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Tom Tromey [EMAIL PROTECTED] wrote: Max == Max Kellermann [EMAIL PROTECTED] writes: Max Does gcj support loading new .JAR files dynamically at run-time Max like with its .WAR files at all (i.e. creating custom ClassLoader Max implementations)? I can hardly imagine how it implements

Re: New on the list - java on debian?

2001-11-13 Thread Max Kellermann
On 0, Alexandre Petit-Bianco [EMAIL PROTECTED] wrote: RHUG's jython relies on that feature to work: jython spits bytecode out of Python files and then interprets them. It is our intent to insert an optional compilation stage. libgcj could then load a shared object instead of a bytecode file.

Re: Classpath and versioned libraries for Debian-Java

2001-11-10 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: No Class-Path at all whenever possible.. remember the example that Xalan2 provides a Xalan1-compatibility layer - it Xalan2 must be included, we can satisfy all Xalan1-dependencies with that library (with lower precedence). Not possible with

Re: Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: I'm a bit curious. In what way is the java extension mechanism useless? The extension mechanism is only there to solve one problem: setting classpath. It does not care about all the other stuff I mentioned. What should I write in my Applet's

Re: Vive la Revolution! (Re: Classpath and versioned libraries for Debian-Java)

2001-11-09 Thread Max Kellermann
On 0, Jeff Turner [EMAIL PROTECTED] wrote: How about using the jar manifest to store the jar metadata, as Sun intended? Make the jars their own database. A platform-independent database :) Jeff, your idea sounds nice, and I would really like to see Debian define the new Java manifest file

Re: Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: I just noticed I mixed library references in Manifest files and Java extensions, but they are similar, and as far as I know them, they're not good. If anyone feels they're sufficient for our problems, please explain :-) I'm not very good at

Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
Hi, let me introduce myself before I go into detail - I am Max Kellermann, I live in Germany near Cologne and I'm 22 years old, I work as software developer (mostly Perl, and some Java). I have learned my first programming language at the age of 9 (Basic, Assembler, Pascal, C++, C, Java, Perl

Re: Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: I'm a bit curious. In what way is the java extension mechanism useless? The extension mechanism is only there to solve one problem: setting classpath. It does not care about all the other stuff I mentioned. What should I write in my Applet's

Re: Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2001 at 11:46:53AM +0100, Max Kellermann wrote: I think so yes. I have not tested it though. Maybe it solves that issue, and maybe not. Anyway this is a java2 thing so we have to make a wrapper (or similar mechanism) for java1. I

Re: Vive la Revolution! (Re: Classpath and versioned libraries for Debian-Java)

2001-11-09 Thread Max Kellermann
On 0, Jeff Turner [EMAIL PROTECTED] wrote: How about using the jar manifest to store the jar metadata, as Sun intended? Make the jars their own database. A platform-independent database :) Jeff, your idea sounds nice, and I would really like to see Debian define the new Java manifest file

Re: Classpath and versioned libraries for Debian-Java

2001-11-09 Thread Max Kellermann
On 0, Ola Lundqvist [EMAIL PROTECTED] wrote: I just noticed I mixed library references in Manifest files and Java extensions, but they are similar, and as far as I know them, they're not good. If anyone feels they're sufficient for our problems, please explain :-) I'm not very good at