Re: Planned mass-filing of bugs: java packages only depending onjava-common
> "Ola" == Ola Lundqvist <[EMAIL PROTECTED]> writes: Ola> This is false. If the package provides the core classes it Ola> should provide java1-runtime but NOT java-virtual-machine. If Ola> it provides the virtual-machine it should provide Ola> java-virtual-machine. If this is not clear enough in policy Ola> that must be clarified. Ola, we go round and round on this. Having java1-runtime only mean the java.* classes doesn't add anything. Packages shouldn't have to depend on two virtual packages; java1-rutime should be a superset of the functionality of java-virual-machine not a disjoint set. -- Stephen "A duck!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planned mass-filing of bugs: java packages only depending onjava-common
> "Ola" == Ola Lundqvist <[EMAIL PROTECTED]> writes: Ola> This is false. If the package provides the core classes it Ola> should provide java1-runtime but NOT java-virtual-machine. If Ola> it provides the virtual-machine it should provide Ola> java-virtual-machine. If this is not clear enough in policy Ola> that must be clarified. Having just reread what you wrote, if you're suggesting that any package providing java1-runtime either depend on or also provide java-virtual-machine, then I agree with you. That still makes classpath wrong as it declares no such dependency. -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planned mass-filing of bugs: java packages only depending on java-common
Stephen, > Ola, we go round and round on this. Having java1-runtime only mean > the java.* classes doesn't add anything. Packages shouldn't have to > depend on two virtual packages; java1-rutime should be a superset of > the functionality of java-virual-machine not a disjoint set. I think the autobuilder argument is valid. Autobuilders need the classes, but not the VM. If at all, you can make the VMs depend on the core classes, so people can depend on the core classes for compiling and a vm for execution. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg02187/pgp0.pgp Description: PGP signature
Re: Planned mass-filing of bugs: java packages only depending onjava-common
> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> I think the autobuilder argument is valid. Autobuilders Simon> need the classes, but not the VM. If at all, you can make Simon> the VMs depend on the core classes, so people can depend on Simon> the core classes for compiling and a vm for execution. Depending on the core classes does not provide javac which is what the autobuilders actually require. GNU classpath, for example, does not provide javac, nor does sablevm. For that you need jikes, kaffe, gcj or the Sun jdk packages. Also, depending on a java-virtual-machine does not provide the java.* classes necessary at *runtime*. A virtual machine is just that, a bytecode interpreter. Java the language != Java the virtual machine. -- Stephen "A duck!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planned mass-filing of bugs: java packages only depending onjava-common
Ok, I should stop reading mail at 3am... > "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> I think the autobuilder argument is valid. Autobuilders Simon> need the classes, but not the VM. If at all, you can make Simon> the VMs depend on the core classes, so people can depend on Simon> the core classes for compiling and a vm for execution. Yes, if the jvm depended on the -runtime that would address half the depndency issue but that's putting the cart before the horse. Having java-compiler depend on java1-runtime might help but in at least two cases that wouyld still result in a jvm being installed so why complicate things? -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planned mass-filing of bugs: java packages only depending onjava-common
Stephen Zander wrote: Depending on the core classes does not provide javac which is what the autobuilders actually require. The build dependencies for Java packages could be for example: jikes, classpath, lib*-java (all other required Java packages) If all lib*-java packages in main depend on java1-runtime (the core classes, not a complete JRE with JVM) this dependency is satisfied by classpath. So I don't need a JVM (which is not available on all architectures) to build the package. Also, depending on a java-virtual-machine does not provide the java.* classes necessary at *runtime*. That's correct. I just changed this for tomcat4 yesterday: It now depends on java-virtual-machine, java2-runtime, ... since I also thought that javaX-runtime meant "core classes + JVM" in the past. Regards, Stefan Gybas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dynamic Array
Dear Java Gurus, I am newbie in java. Please point me on Handling Dynamic Array of String like String[][]. In my case Vector is not suitable. -- Odo <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dynamic Array
> Dear Java Gurus, hello and thanks a lot for calling me a guru > I am newbie in java. > Please point me on Handling Dynamic Array of String like String[][]. In > my case Vector is not suitable. I think you have missed the point. This list is for solving the issues that araise with java on debian. Debian specific only. for your problem i think you sould (order is important) - read sun tutorial http://java.sun.com/docs/books/tutorial/index.html - read sun doc http://java.sun.com/docs/ - optionnal (but you could appreciate it) - search the web with google (don't forget to search google groups) - ask on usenet I think that for your probleme step 3 should be enough BTW if you want to try to ask a question on usenet or on a web forum try to be more accurate. If explainning dynamic Array is too loong, explaining and solving a very precise issue is not. have a nice day jeff -- Paris jean-francois | CLE PUBLIQUE PGP&GPG [EMAIL PROTECTED] | DH/DSS ID: 0xBF4B709E [EMAIL PROTECTED] | http://mjediyoda.free.fr/ If you use envelopes, why not use encryption? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Planned mass-filing of bugs: java packages only depending on java-common
> "Stefan" == Stefan Gybas <[EMAIL PROTECTED]> writes: Stefan> Currently the following packages in testing provide Stefan> java1-runtime: gij-3.0, gij-3.2, orp-classpath and Stefan> sablevm. All of them include (or depend on) a Java virtual Stefan> machine so if I add this dependecy to the lib*-java Stefan> packages I end up with a de-facto dependency on a virtual Stefan> machine (which is e.g. not needed for autobuilders). Could Stefan> you first file bug reports against all Java apckages that Stefan> should provide java1-runtime (like classpath)? Actually, classpath shouldn't provide java1-runtime unless it includes or depends on a Java virtual machine. I will, however file bugs on any packages that provide or depend on java-virtual-machine and don't provide java1-runtime bu should. -- Stephen To Republicans, limited government means not assisting people they would sooner see shoveled into mass graves. -- Kenneth R. Kahn
Re: Planned mass-filing of bugs: java packages only depending on java-common
On Wed, Dec 04, 2002 at 10:43:55PM -0800, Stephen Zander wrote: > > "Stefan" == Stefan Gybas <[EMAIL PROTECTED]> writes: > Stefan> Currently the following packages in testing provide > Stefan> java1-runtime: gij-3.0, gij-3.2, orp-classpath and > Stefan> sablevm. All of them include (or depend on) a Java virtual > Stefan> machine so if I add this dependecy to the lib*-java > Stefan> packages I end up with a de-facto dependency on a virtual > Stefan> machine (which is e.g. not needed for autobuilders). Could > Stefan> you first file bug reports against all Java apckages that > Stefan> should provide java1-runtime (like classpath)? > > Actually, classpath shouldn't provide java1-runtime unless it includes > or depends on a Java virtual machine. I will, however file bugs on > any packages that provide or depend on java-virtual-machine and don't > provide java1-runtime bu should. This is false. If the package provides the core classes it should provide java1-runtime but NOT java-virtual-machine. If it provides the virtual-machine it should provide java-virtual-machine. If this is not clear enough in policy that must be clarified. Regards, // Ola > -- > Stephen > > To Republicans, limited government means not assisting people they > would sooner see shoveled into mass graves. -- Kenneth R. Kahn > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Planned mass-filing of bugs: java packages only depending on java-common
> "Ola" == Ola Lundqvist <[EMAIL PROTECTED]> writes: Ola> This is false. If the package provides the core classes it Ola> should provide java1-runtime but NOT java-virtual-machine. If Ola> it provides the virtual-machine it should provide Ola> java-virtual-machine. If this is not clear enough in policy Ola> that must be clarified. Ola, we go round and round on this. Having java1-runtime only mean the java.* classes doesn't add anything. Packages shouldn't have to depend on two virtual packages; java1-rutime should be a superset of the functionality of java-virual-machine not a disjoint set. -- Stephen "A duck!"
Re: Planned mass-filing of bugs: java packages only depending on java-common
> "Ola" == Ola Lundqvist <[EMAIL PROTECTED]> writes: Ola> This is false. If the package provides the core classes it Ola> should provide java1-runtime but NOT java-virtual-machine. If Ola> it provides the virtual-machine it should provide Ola> java-virtual-machine. If this is not clear enough in policy Ola> that must be clarified. Having just reread what you wrote, if you're suggesting that any package providing java1-runtime either depend on or also provide java-virtual-machine, then I agree with you. That still makes classpath wrong as it declares no such dependency. -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
Re: Planned mass-filing of bugs: java packages only depending on java-common
Stephen, > Ola, we go round and round on this. Having java1-runtime only mean > the java.* classes doesn't add anything. Packages shouldn't have to > depend on two virtual packages; java1-rutime should be a superset of > the functionality of java-virual-machine not a disjoint set. I think the autobuilder argument is valid. Autobuilders need the classes, but not the VM. If at all, you can make the VMs depend on the core classes, so people can depend on the core classes for compiling and a vm for execution. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpO55TeC2efV.pgp Description: PGP signature
Re: Planned mass-filing of bugs: java packages only depending on java-common
> "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> I think the autobuilder argument is valid. Autobuilders Simon> need the classes, but not the VM. If at all, you can make Simon> the VMs depend on the core classes, so people can depend on Simon> the core classes for compiling and a vm for execution. Depending on the core classes does not provide javac which is what the autobuilders actually require. GNU classpath, for example, does not provide javac, nor does sablevm. For that you need jikes, kaffe, gcj or the Sun jdk packages. Also, depending on a java-virtual-machine does not provide the java.* classes necessary at *runtime*. A virtual machine is just that, a bytecode interpreter. Java the language != Java the virtual machine. -- Stephen "A duck!"
Re: Planned mass-filing of bugs: java packages only depending on java-common
Ok, I should stop reading mail at 3am... > "Simon" == Simon Richter <[EMAIL PROTECTED]> writes: Simon> I think the autobuilder argument is valid. Autobuilders Simon> need the classes, but not the VM. If at all, you can make Simon> the VMs depend on the core classes, so people can depend on Simon> the core classes for compiling and a vm for execution. Yes, if the jvm depended on the -runtime that would address half the depndency issue but that's putting the cart before the horse. Having java-compiler depend on java1-runtime might help but in at least two cases that wouyld still result in a jvm being installed so why complicate things? -- Stephen "If I claimed I was emporer just cause some moistened bint lobbed a scimitar at me they'd put me away"
Re: Planned mass-filing of bugs: java packages only depending on java-common
Stephen Zander wrote: Depending on the core classes does not provide javac which is what the autobuilders actually require. The build dependencies for Java packages could be for example: jikes, classpath, lib*-java (all other required Java packages) If all lib*-java packages in main depend on java1-runtime (the core classes, not a complete JRE with JVM) this dependency is satisfied by classpath. So I don't need a JVM (which is not available on all architectures) to build the package. Also, depending on a java-virtual-machine does not provide the java.* classes necessary at *runtime*. That's correct. I just changed this for tomcat4 yesterday: It now depends on java-virtual-machine, java2-runtime, ... since I also thought that javaX-runtime meant "core classes + JVM" in the past. Regards, Stefan Gybas
Dynamic Array
Dear Java Gurus, I am newbie in java. Please point me on Handling Dynamic Array of String like String[][]. In my case Vector is not suitable. -- Odo <[EMAIL PROTECTED]>
