Re: Gcj version of Jar

2003-09-03 Thread Dalibor Topic
--- David Goodenough [EMAIL PROTECTED] wrote: Does anyone know that the GCJ version of Jar is? If not is there an open source version of Jar somewhere. Its close to zip of course, but just not quite close enough, and the options are more like those from tar. gcj comes with a jar tool

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Dalibor, * Dalibor Topic wrote: So when I write kaffe -bootclasspath xerces.jar .. -cp ... Main I can't do it, because its against the GPL/whetever License? I'm not sure. Technically of course you can do it, but I don't think

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Dalibor, * Dalibor Topic wrote: Packages, which want to contribute a alternative for /usr/bin/java and its manpage must provide java-runtime. The alternative must accept the option '-classpath', which sets the classpath and

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
--- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Matt, [snip] This interface is not for the free ones but only for the sun complient ones (Sun, BD, IBM). The rest will be handled independently. [snip] With this interfaces you can install a package and know that it will run, even if you

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: And the thing is, it will work. JAVA_HOME is not advertised anywhere, but almost every startscript uses it. man ant, man eclipse, man tomcat4 (oups: No manual entry for tomcat4, which tomcat4: /usr/bin/tomcat4). All use it, but no word in

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Matt Zimmerman
On Wed, Sep 03, 2003 at 09:29:23AM +1000, Ben Burton wrote: In addition, if a user wants to add their own classes to the classpath (e.g., with jython where adding your own classes can be advantageous even if the app itself doesn't need them), they can set $CLASSPATH before running the script.

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Ben, * Ben Burton wrote: Can we use $CLASSPATH instead of -classpath? From my experience making packages work with both free and proprietary JVMs, setting $CLASSPATH before calling the java runtime (instead of passing -classpath, -cp, whatever) has caused the least breakage. With some

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: -classpath jarfile:jarfile, where jarfile is a full path to a Java Archiv file. So you've just forbid the use of directories in -classpath per policy. Are you sure you want to do that? ;) In packages: yes. Policy requires, that all puiblic jar files are

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: Kaffe is actually mostly compatible with the JAVA_HOME standard now that I use symlinks for Debian compatibility. It might be worth making the JAVA_HOME structure part of Debian policy. GCJ and friends could create some simulation of it by symlinking

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Ben Burton
Can we use $CLASSPATH instead of -classpath? From my experience making packages work with both free and proprietary JVMs, setting $CLASSPATH before calling the java runtime (instead of passing -classpath, -cp, whatever) has caused the least breakage. With some clear idea about *what* you

Gcj version of Jar

2003-09-03 Thread David Goodenough
Does anyone know that the GCJ version of Jar is? If not is there an open source version of Jar somewhere. Its close to zip of course, but just not quite close enough, and the options are more like those from tar. David

Re: Gcj version of Jar

2003-09-03 Thread Dalibor Topic
--- David Goodenough [EMAIL PROTECTED] wrote: Does anyone know that the GCJ version of Jar is? If not is there an open source version of Jar somewhere. Its close to zip of course, but just not quite close enough, and the options are more like those from tar. gcj comes with a jar tool

Re: Gcj version of Jar

2003-09-03 Thread David Goodenough
On Wednesday 03 September 2003 08:57, Dalibor Topic wrote: --- David Goodenough [EMAIL PROTECTED] wrote: Does anyone know that the GCJ version of Jar is? If not is there an open source version of Jar somewhere. Its close to zip of course, but just not quite close enough, and the options

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Dalibor, * Dalibor Topic wrote: So when I write kaffe -bootclasspath xerces.jar .. -cp ... Main I can't do it, because its against the GPL/whetever License? I'm not sure. Technically of course you can do it, but I don't think

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Dalibor, * Dalibor Topic wrote: A precise interface should be discussed together. Off my head: -classpath, -cp, -sourcepath, -O, -d, -g, -deprecation I'd remove a few things from the list, since javac 1.4.2 doesn't support -cp

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
Hallo Jan, --- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Dalibor, * Dalibor Topic wrote: Packages, which want to contribute a alternative for /usr/bin/java and its manpage must provide java-runtime. The alternative must accept the option '-classpath', which sets the classpath and

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Dalibor Topic
--- Jan Schulz [EMAIL PROTECTED] wrote: Hallo Matt, [snip] This interface is not for the free ones but only for the sun complient ones (Sun, BD, IBM). The rest will be handled independently. [snip] With this interfaces you can install a package and know that it will run, even if you

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Matt Zimmerman
On Wed, Sep 03, 2003 at 09:29:23AM +1000, Ben Burton wrote: In addition, if a user wants to add their own classes to the classpath (e.g., with jython where adding your own classes can be advantageous even if the app itself doesn't need them), they can set $CLASSPATH before running the script.

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL states that such things happen when you use JNI with GPL code. Anyway, I'm neither a laywer, nor in any way experienced enough with such a question. The ugly point is that almost every VM

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Ean, * Ean Schuessler wrote: On Tue, 2003-09-02 at 16:10, Jan Schulz wrote: The difference is that the Kaffe package would not try to provide j2sdk1.4. Kaffe just provides kaffe. Packages that know they will work with Kaffe can explicitly depend on it. Sorry, if I haven't made that clear

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Ben Burton
This is somewhat more difficult to arrange with command-line options. java -classpath foo.jar:bar.jar:$CLASSPATH Heh. :) *slap*

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Ben, * Ben Burton wrote: Can we use $CLASSPATH instead of -classpath? From my experience making packages work with both free and proprietary JVMs, setting $CLASSPATH before calling the java runtime (instead of passing -classpath, -cp, whatever) has caused the least breakage. With some

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: -classpath jarfile:jarfile, where jarfile is a full path to a Java Archiv file. So you've just forbid the use of directories in -classpath per policy. Are you sure you want to do that? ;) In packages: yes. Policy requires, that all puiblic jar files are

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: it is names) and it should be fine. If thats the search path for classes... Without, we probably can't use kjc, as a javac replacement or ant compiler, as the result would be unpredictable, especially when a programm wants to have a newer version of one

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: If the packages need java, the executable, they should use whatever 'java' is in the PATH. If they need it to load sun.only.dedicated.morons.use.this.api.Main, then they are broken and need to be fixed. There is no reason to use JAVA_HOME. I think we just

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: I sense a contradiction here. Either the interface is meant for non-compliant free VMs as well, then the first paragraph is weird, or the free VMs will be handled separately, but then there is no interface, so the second paragraph is, huh, weird ;) Aem,

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Jan Schulz
Hallo Dalibor, * Dalibor Topic wrote: Kaffe is actually mostly compatible with the JAVA_HOME standard now that I use symlinks for Debian compatibility. It might be worth making the JAVA_HOME structure part of Debian policy. GCJ and friends could create some simulation of it by symlinking

Re: [PROPOSAL] New Virtual Packages and way to handle Classpath

2003-09-03 Thread Ben Burton
Can we use $CLASSPATH instead of -classpath? From my experience making packages work with both free and proprietary JVMs, setting $CLASSPATH before calling the java runtime (instead of passing -classpath, -cp, whatever) has caused the least breakage. With some clear idea about *what* you