On Thu, Dec 05, 2002 at 02:55:22AM -0800, Stephen Zander wrote:
>
Hi
There are several reasons why they are split.
1) some compilers do not require a jvm.
2) Some things compile the classes to bytecode the will not
need the jvm. This is why it is very explictly written in the
java policy
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
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
> "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 c
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 a
> "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 no
> "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 no
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
> "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 depen
On Wed, Nov 27, 2002 at 09:33:49AM -0800, Stephen Zander wrote:
> To that end I will be filing important bugs against any lib*-java
> package that does not depend on either java1-runtime or java2-runtime
> (should the package required features of the standard java.* classes
> that are only include
> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> errr... shouldn't you decide on the name first, then file
Brian> bug reports?
A reasonable point & I'll do so. I don't, however, expect the name to
change as that would introduce a third virtual package into the mix.
Tow, java-
On Wed, Nov 27, 2002 at 09:33:49AM -0800, Stephen Zander wrote:
> To that end I will be filing important bugs against any lib*-java
> package that does not depend on either java1-runtime or java2-runtime
> (should the package required features of the standard java.* classes
> that are only included
There are a significant number of lib*-java packages whose only
dependency is on java-common. While the java policy has condoned this
behaviour in the past, it is non-sensical to do in the same way it is
non-sensical of C libraries not to depend on libc. This is due to the
use of standard java.*
13 matches
Mail list logo
