javac can also be called during package building.
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
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
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
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.
--- 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 write
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 will work.
--- 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
be
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 Sun's
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
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
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 used.
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
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
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
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
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 VMs
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 specify what
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
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
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.
--- 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 write
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 about
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 will work.
--- 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
be
--- 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
be
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 Sun's
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
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
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 used.
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 | kaffe, etc.
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 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
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 package [...] and
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
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 than
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
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 VMs
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
38 matches
Mail list logo
