> I think we should distinguish are two different kinds of builds:
> 1) by the Debian build daemon
> 2) by a user that downloaded the package source
Both of these must still work out of the box. In particular, as a user
I should be able to apt-get source foo-java and just build it without
ha
> > 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
> > autmatically adds the right rt.jar. The must depend on java-common.
>
> You need to speci
On Tue, 2003-09-02 at 16:10, Jan Schulz wrote:
> And how is that differently from my aproach? j2sdk1.4 is just a word
> for 'Sun compatible J2sdk of version 1.4'. mpkg-j2sdk will make a
> package with that name from the sun -bin download (BD gets
> j2sdk1.4-bd). So you are basicly hiding working VM
Hallo T.,
* T. Alexander Popiel wrote:
>>The rest will be handled independently.
>How, though? If an application is known to work with kaffe or sablevm
>or Sun's java, how is that application to pick which to use on invocation?
>Will each application have to have a wrapper script which picks an
Hallo Ean,
* Ean Schuessler wrote:
>I'm afraid that I agree with Matt. As much as I like the idea of
>abstract dependencies it seems that it will become much more complex and
>much harder than just depending on a runtime that is known to work. The
>core issue being that there are far fewer VMs tha
Hallo Matt,
* Matt Zimmerman wrote:
>> This interface is not for the free ones but only for the sun complient
>> ones (Sun, BD, IBM). The rest will be handled independently.
>Independently how? I admit I am primarily interested in how java VMs and
>development tools in Debian will work with java
> I think we should distinguish are two different kinds of builds:
> 1) by the Debian build daemon
> 2) by a user that downloaded the package source
Both of these must still work out of the box. In particular, as a user
I should be able to apt-get source foo-java and just build it without
ha
> > 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
> > autmatically adds the right rt.jar. The must depend on java-common.
>
> You need to speci
On Tue, 2003-09-02 at 16:10, Jan Schulz wrote:
> And how is that differently from my aproach? j2sdk1.4 is just a word
> for 'Sun compatible J2sdk of version 1.4'. mpkg-j2sdk will make a
> package with that name from the sun -bin download (BD gets
> j2sdk1.4-bd). So you are basicly hiding working VM
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
>* Matt Zimmerman wrote:
>
>>I like some of the ideas in your proposal, but things like "Java Runtime
>>Environments, which are complient to the Java Spec of a specific Version,
>>have to provide the virtual packag
Hallo T.,
* T. Alexander Popiel wrote:
>>The rest will be handled independently.
>How, though? If an application is known to work with kaffe or sablevm
>or Sun's java, how is that application to pick which to use on invocation?
>Will each application have to have a wrapper script which picks an
Hallo Ean,
* Ean Schuessler wrote:
>I'm afraid that I agree with Matt. As much as I like the idea of
>abstract dependencies it seems that it will become much more complex and
>much harder than just depending on a runtime that is known to work. The
>core issue being that there are far fewer VMs tha
Hallo Matt,
* Matt Zimmerman wrote:
>> This interface is not for the free ones but only for the sun complient
>> ones (Sun, BD, IBM). The rest will be handled independently.
>Independently how? I admit I am primarily interested in how java VMs and
>development tools in Debian will work with java
On Tue, Sep 02, 2003 at 09:21:22PM +0200, Jan Schulz wrote:
> * Matt Zimmerman wrote:
> >I like some of the ideas in your proposal, but things like "Java Runtime
> >Environments, which are complient to the Java Spec of a specific Version,
> >have to provide the virtual package [...] and setup alte
Hallo Matt,
* Matt Zimmerman wrote:
>On Tue, Sep 02, 2003 at 06:58:58PM +0200, Jan Schulz wrote:
>> The interface java2-runtime means, that /usr/bin/java can be used.
>Which is not a useful concept, because almost no nontrivial applications can
>work with everything which currently provides /usr/b
In message: <[EMAIL PROTECTED]>
Jan Schulz <[EMAIL PROTECTED]> writes:
>* Matt Zimmerman wrote:
>
>>I like some of the ideas in your proposal, but things like "Java Runtime
>>Environments, which are complient to the Java Spec of a specific Version,
>>have to provide the virtual packag
I'm afraid that I agree with Matt. As much as I like the idea of
abstract dependencies it seems that it will become much more complex and
much harder than just depending on a runtime that is known to work. The
core issue being that there are far fewer VMs than there are possible
base class library
On Tue, Sep 02, 2003 at 06:58:58PM +0200, Jan Schulz wrote:
> Hallo Matt,
>
> * Matt Zimmerman wrote:
> >and not an abstract idea of what is provided. For example, a package which
> >works with any java2 runtime, but also works with the interfaces provided by
> >kaffe, uses "java2-runtime | kaff
On Tue, Sep 02, 2003 at 09:21:22PM +0200, Jan Schulz wrote:
> * Matt Zimmerman wrote:
> >I like some of the ideas in your proposal, but things like "Java Runtime
> >Environments, which are complient to the Java Spec of a specific Version,
> >have to provide the virtual package [...] and setup alte
Hallo Matt,
* Matt Zimmerman wrote:
>On Tue, Sep 02, 2003 at 06:58:58PM +0200, Jan Schulz wrote:
>> The interface java2-runtime means, that /usr/bin/java can be used.
>Which is not a useful concept, because almost no nontrivial applications can
>work with everything which currently provides /usr/b
Hallo Matt,
* Matt Zimmerman wrote:
>and not an abstract idea of what is provided. For example, a package which
>works with any java2 runtime, but also works with the interfaces provided by
>kaffe, uses "java2-runtime | kaffe", etc.
The interface java2-runtime means, that /usr/bin/java can be us
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 you can
>distribute the resulting work. So when your bo
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
>and javac 1.4.2 doesn't support -O.
I thought that jav
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 autmatically adds the right
>> rt.jar. The must depend on j
I'm afraid that I agree with Matt. As much as I like the idea of
abstract dependencies it seems that it will become much more complex and
much harder than just depending on a runtime that is known to work. The
core issue being that there are far fewer VMs than there are possible
base class library
On Tue, Sep 02, 2003 at 06:58:58PM +0200, Jan Schulz wrote:
> Hallo Matt,
>
> * Matt Zimmerman wrote:
> >and not an abstract idea of what is provided. For example, a package which
> >works with any java2 runtime, but also works with the interfaces provided by
> >kaffe, uses "java2-runtime | kaff
Hallo Matt,
* Matt Zimmerman wrote:
>and not an abstract idea of what is provided. For example, a package which
>works with any java2 runtime, but also works with the interfaces provided by
>kaffe, uses "java2-runtime | kaffe", etc.
The interface java2-runtime means, that /usr/bin/java can be us
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 you can
>distribute the resulting work. So when your bo
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
>and javac 1.4.2 doesn't support -O.
I thought that jav
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 autmatically adds the right
>> rt.jar. The must depend on j
On Fri, Aug 29, 2003 at 06:58:46PM -0500, Ean Schuessler wrote:
> We must come to terms with the fact that a Debian Java policy cannot be
> built with proprietary VMs in mind. There is no "make it work" when it
> comes to proprietary software and Debian.
The problem, as I see it, is that Java co
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
> >My gut feeling is that one needs to be very careful as a distributor of
> >copyrighted works not to create derived works that violate the licenses of
> >involved works. Adding missing classes to kaffe's bootclasspath from Su
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 2.1. Virtual machines
>
> As it is nearly impossible to treat all java virtual maschines the same,
> JVMs are seperated into two kinds: sun compatible and not. The first ones
> should be used via the below interface, every other virtual maschine has to
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 2.1. Virtual machines
>
> As it is nearly impossible to treat all java virtual maschines the same,
> JVMs are seperated into two kinds: sun compatible and not. The first ones
> should be used via the below interface, every other virtual maschine has to
Hallo Daniel,
* Daniel Bonniot wrote:
>>FWIW, I think having a package build relying on /usr/bin/javac is a very
>>bad idea. You want to be absolutely sure that a package builds out of
>>the box, and IMHO this means you should explicitly build-depend upon
>>*and* call a complier that you know wil
On Fri, Aug 29, 2003 at 06:58:46PM -0500, Ean Schuessler wrote:
> We must come to terms with the fact that a Debian Java policy cannot be
> built with proprietary VMs in mind. There is no "make it work" when it
> comes to proprietary software and Debian.
The problem, as I see it, is that Java co
Ciao Stefano,
Freenet releases that don't use NIO should run on latest kaffe (1.1.1), as well
as Mark Wielaard's java bittorrent client snark.
cheers,
dalibor topic
--- MJ Ray <[EMAIL PROTECTED]> wrote:
> Stefano Maffulli <[EMAIL PROTECTED]> asked me the following question,
> after being asked
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
> >My gut feeling is that one needs to be very careful as a distributor of
> >copyrighted works not to create derived works that violate the licenses of
> >involved works. Adding missing classes to kaffe's bootclasspath from Su
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
>
> >What interface do you suggest? The discussion her pretty much showed,
> >that you can't rely on anything. This would mean:
> >* -classpath is probably save (-cp already not...)
> >
> I think we should define an interface in the Java policy, then
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 2.1. Virtual machines
>
> As it is nearly impossible to treat all java virtual maschines the same,
> JVMs are seperated into two kinds: sun compatible and not. The first ones
> should be used via the below interface, every other virtual maschine has to
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 2.1. Virtual machines
>
> As it is nearly impossible to treat all java virtual maschines the same,
> JVMs are seperated into two kinds: sun compatible and not. The first ones
> should be used via the below interface, every other virtual maschine has to
Hallo Daniel,
* Daniel Bonniot wrote:
>>FWIW, I think having a package build relying on /usr/bin/javac is a very
>>bad idea. You want to be absolutely sure that a package builds out of
>>the box, and IMHO this means you should explicitly build-depend upon
>>*and* call a complier that you know wil
Stefano Maffulli <[EMAIL PROTECTED]> asked me the following question,
after being asked about Java peer-to-peer software. I will mention
bittorrent to him as something to look into. I don't know the answer
to the jxta part, so I'd appreciate it if anyone on debian-java could
cc him a reply.
FWIW, I think having a package build relying on /usr/bin/javac is a very
bad idea. You want to be absolutely sure that a package builds out of
the box, and IMHO this means you should explicitly build-depend upon
*and* call a complier that you know will work. Note that just the
build-depends is n
What interface do you suggest? The discussion her pretty much showed,
that you can't rely on anything. This would mean:
* -classpath is probably save (-cp already not...)
I think we should define an interface in the Java policy, then write
wrappers for the different compilers, and install the wra
Ciao Stefano,
Freenet releases that don't use NIO should run on latest kaffe (1.1.1), as well
as Mark Wielaard's java bittorrent client snark.
cheers,
dalibor topic
--- MJ Ray <[EMAIL PROTECTED]> wrote:
> Stefano Maffulli <[EMAIL PROTECTED]> asked me the following question,
> after being asked
--- Daniel Bonniot <[EMAIL PROTECTED]> wrote:
>
> >What interface do you suggest? The discussion her pretty much showed,
> >that you can't rely on anything. This would mean:
> >* -classpath is probably save (-cp already not...)
> >
> I think we should define an interface in the Java policy, then
Stefano Maffulli <[EMAIL PROTECTED]> asked me the following question,
after being asked about Java peer-to-peer software. I will mention
bittorrent to him as something to look into. I don't know the answer
to the jxta part, so I'd appreciate it if anyone on debian-java could
cc him a reply.
FWIW, I think having a package build relying on /usr/bin/javac is a very
bad idea. You want to be absolutely sure that a package builds out of
the box, and IMHO this means you should explicitly build-depend upon
*and* call a complier that you know will work. Note that just the
build-depends is n
What interface do you suggest? The discussion her pretty much showed,
that you can't rely on anything. This would mean:
* -classpath is probably save (-cp already not...)
I think we should define an interface in the Java policy, then write
wrappers for the different compilers, and install the wra
50 matches
Mail list logo
