Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
2.6. Java programs
[...]
Applications may honor the user set JAVA_HOME evironment variable,
while looking for a useable java virtual maschine. If so, this must
be clearly stated in the manpage and, if possible, at
Hallo Grzegorz,
Only a reply to the list, as this won't help before the sarge release.
* Grzegorz B. Prokopski wrote:
The problem is that jikes privides wrappers which depend on every
possible JVM in Debian. [...]
Probably the proper fix for that would be that creation of wrappers
should be only
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
Ok, I don't actually mind. The only real argument I have is that it
looks better, if you have all requirements defined with comandline
arguments, not environment variables. But ok... neither gij-3.0 nor
gij-wrapper-3.0 have a -classpath
Hi. Just a few more notes on this.
Java libraries must depend on the needed working runtime
environments, including the virtual package names of working
versions of the unfree bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
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
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
Chapter 2. Policy
Packages written in Java are separated in two categories: programs
and libraries. Programs are intended to be run by end-users.
Libraries are intended
Are there any other requirements? Should /lib and /usr/lib be searched
or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
normal application libraries).
In particular, java policy also
Hallo Mark,
* Mark Wielaard wrote:
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
--8-:- snip -:-8-:- snip -:-8--
[EMAIL PROTECTED]:/$ gij-3.0 --help
Usage: gij [OPTION] ... CLASS
Hi,
On Sat, 2003-09-06 at 17:29, Jan Schulz wrote:
* Mark Wielaard wrote:
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
--8-:- snip -:-8-:- snip -:-8--
[EMAIL PROTECTED]:/$
--- Grzegorz B. Prokopski [EMAIL PROTECTED] wrote:
Package: jikes
Version: 1.18-6
Severity: wishlist
Hi all!
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which is important
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which is important from testing migration scripts POV) depends of
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Dalibor,
* Dalibor Topic wrote:
I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should
be
in there, or how it should work. It's just a part of the ugly java folklore,
like trigraphs in C. ;)
But it has a
On Sat, 2003-09-06 at 14:32, Matt Zimmerman wrote:
What you are missing is that Debian binary packages must stay in sync with
their source package, which means that all of the packages that jikes builds
are handled as a group for release purposes.
If this is causing a problem, the obvious
Hi Matt,
--- Matt Zimmerman [EMAIL PROTECTED] wrote:
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Ean,
* Ean Schuessler wrote:
The problem is that java2-runtime-spec-version doesn't really
provide anything more than j2re1.4. It is just a wordier way to refer
to Sun and IBM's VM, neither of which can actually be distributed by
Hallo Mark,
* Mark Wielaard wrote:
Try gij-3.3:
Don't have that just now... Yes, unstable is calling, even starting to
scream...
All compilers I know should be satisfied by that.
OK. I am not a big Ant user. gcj needs a -C option to compile to byte
code though. Or a --main package.MainClass
Hallo Dalibor,
* Dalibor Topic wrote:
[rant about JAVA_HOME]
I don't think that's a good foundation to build a policy on ;)
Is the current proposal better?
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
--
To UNSUBSCRIBE, email to [EMAIL
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
The problem in debian is to find out this java.
This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class
From debian I'd expect a policy that helps and guides java
apps/libs/jvm
maintainers to build and package their stuff with a focus on free
VMs, gives pointers who to get in topuch with if things don't work,
has a section on free java developers working on providing a free
java
On Fri, Sep 05, 2003 at 10:16:53PM -0400, Grzegorz B. Prokopski wrote:
Package: jikes
Version: 1.18-6
Severity: wishlist
Please don't CC other addresses when mailing [EMAIL PROTECTED] Read the BTS
documentation about the X-Debbugs-CC header.
--
- mdz
On Sat, 2003-09-06 at 00:36, Matt Zimmerman wrote:
On Fri, Sep 05, 2003 at 10:16:53PM -0400, Grzegorz B. Prokopski wrote:
Package: jikes
Version: 1.18-6
Severity: wishlist
Please don't CC other addresses when mailing [EMAIL PROTECTED] Read the BTS
documentation about the X-Debbugs-CC
Hallo Jan,
Just a smal update, which I forgot last night...
* Jan Schulz wrote:
2.6. Java programs
[...]
Applications may honor the user set JAVA_HOME evironment variable,
while looking for a useable java virtual maschine. If so, this must
be clearly stated in the manpage and, if possible, at
Hallo Grzegorz,
Only a reply to the list, as this won't help before the sarge release.
* Grzegorz B. Prokopski wrote:
The problem is that jikes privides wrappers which depend on every
possible JVM in Debian. [...]
Probably the proper fix for that would be that creation of wrappers
should be only
Hi,
On Fri, 2003-09-05 at 20:21, Jan Schulz wrote:
Ok, I don't actually mind. The only real argument I have is that it
looks better, if you have all requirements defined with comandline
arguments, not environment variables. But ok... neither gij-3.0 nor
gij-wrapper-3.0 have a -classpath
Hi. Just a few more notes on this.
Java libraries must depend on the needed working runtime
environments, including the virtual package names of working
versions of the unfree bin/java interface.
(and a similar clause for java programs)
If you're going to mandate that developers keep a
If the discussed proposal is used, this will be the only way to do it.
- A 'ant environment', which will use jikes as a compiler, will set
the ANT_BUILD_COMPILER to jikes and ant will use jikes as a compiler.
What if I don't want to use ant?
The current jikes-* wrappers let me drop in
Hi,
I am one of the GNU Classpath developers but not a Debian developer.
On Sat, 2003-09-06 at 01:47, Jan Schulz wrote:
Chapter 2. Policy
Packages written in Java are separated in two categories: programs
and libraries. Programs are intended to be run by end-users.
Libraries are intended
Are there any other requirements? Should /lib and /usr/lib be searched
or not for example?
The reason for the /usr/lib/jni addition to policy was to get JNI
modules out of /usr/lib directly (since they're dlopened modules, not
normal application libraries).
In particular, java policy also
Hallo Mark,
* Mark Wielaard wrote:
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
--8-:- snip -:-8-:- snip -:-8--
[EMAIL PROTECTED]:/$ gij-3.0 --help
Usage: gij [OPTION] ... CLASS
Hallo Ben,
* Ben Burton wrote:
Java libraries must depend on the needed working runtime
environments, including the virtual package names of working
versions of the unfree bin/java interface.
If you're going to mandate that developers keep a list of working JVMs
for their dependencies, you
Hallo Mark,
* Mark Wielaard wrote:
I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
For end-user programs I think it would be a good idea to mention that
gcj can be used to compile programs written in the java language into
normal native binaries
Hi,
On Sat, 2003-09-06 at 17:29, Jan Schulz wrote:
* Mark Wielaard wrote:
gij does come with a normal long-option --classpath. But as the gij help
output says: Options can be specified with `-' or `--'.
--8-:- snip -:-8-:- snip -:-8--
[EMAIL PROTECTED]:/$
--- Grzegorz B. Prokopski [EMAIL PROTECTED] wrote:
Package: jikes
Version: 1.18-6
Severity: wishlist
Hi all!
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which is important
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which is important from testing migration scripts POV) depends of
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Dalibor,
* Dalibor Topic wrote:
And finally, what's the effect of -classpath a.jar:b.jar supposed to
be? How does it alter the class lookup? What about the current
directory? Is that included automatically? And so on ...
If we
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
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
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Dalibor,
* Dalibor Topic wrote:
I doubt it. JAVA_HOME isn't specified anywhere by Sun AFAIK, nor what should
be
in there, or how it should work. It's just a part of the ugly java folklore,
like trigraphs in C. ;)
But it has a
On Sat, 2003-09-06 at 14:32, Matt Zimmerman wrote:
What you are missing is that Debian binary packages must stay in sync with
their source package, which means that all of the packages that jikes builds
are handled as a group for release purposes.
If this is causing a problem, the obvious
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Dalibor,
* Dalibor Topic wrote:
I wanted to say, that you have a interface for the 'unfree' ones and
this interface will work, even if you have 'not working' JVM
installed. The current interface (/usr/bin/java) does not garantee,
Hi,
On Sat, 2003-09-06 at 19:15, Jan Schulz wrote:
* Mark Wielaard wrote:
I am one of the GNU Classpath developers but not a Debian developer.
Thanks for joining anyway :)
I am a Debian user though and use it for all my development machines.
For end-user programs I think it would be a
Hi Matt,
--- Matt Zimmerman [EMAIL PROTECTED] wrote:
On Sat, Sep 06, 2003 at 11:11:06AM -0700, Dalibor Topic wrote:
I used to be very busy/without net during last months but I am back.
And attacking ;-)
The problem is that currently jikes (in the sense of source package,
which
Hallo Jan,
--- Jan Schulz [EMAIL PROTECTED] wrote:
Hallo Ean,
* Ean Schuessler wrote:
The problem is that java2-runtime-spec-version doesn't really
provide anything more than j2re1.4. It is just a wordier way to refer
to Sun and IBM's VM, neither of which can actually be distributed by
Hallo Mark,
* Mark Wielaard wrote:
Try gij-3.3:
Don't have that just now... Yes, unstable is calling, even starting to
scream...
All compilers I know should be satisfied by that.
OK. I am not a big Ant user. gcj needs a -C option to compile to byte
code though. Or a --main package.MainClass
Hallo Dalibor,
* Dalibor Topic wrote:
Why do you assume familiarity with some command line synopsis? The effect of
-classpath a.jar:b.jar for example can have different effects depending on the
VM used, and its version. That's what the documentation is good for ;)
From my limited java
Hallo Dalibor,
* Dalibor Topic wrote:
[rant about JAVA_HOME]
I don't think that's a good foundation to build a policy on ;)
Is the current proposal better?
Jan
--
Jan Schulz [EMAIL PROTECTED]
Wer nicht fragt, bleibt dumm.
Hallo Dalibor,
* Dalibor Topic wrote:
Currently you forbit this, as you only know where the BD package put
their java and so it will break if you have sun-java packaged
(mpkg-j2sdk) and instaleld with that name.
Can't the maintainers of Blackdown Java and mpkg-j2sdk resolve this naming
issue
Hallo Dalibor,
* Dalibor Topic wrote:
I wanted to say, that you have a interface for the 'unfree' ones and
this interface will work, even if you have 'not working' JVM
installed. The current interface (/usr/bin/java) does not garantee,
that your package is working.
I don't think that an
Hallo Dalibor,
* Dalibor Topic wrote:
I haven't used JNI much, so it would be nice if someone who packages a JNI
library could chip in here and provide some insight about what's necesary, and
how they use to find it.
Same as usuall in the builds: get a JAVA_HOME and pass $JAVA_HOME/includes and
Hi Jan,
On Sat, 2003-09-06 at 22:26, Jan Schulz wrote:
The problem in debian is to find out this java.
This should be adressed in this proposal.
Why this fixation on this one program name?
I know there is a non-free environment called java that is a
interpreter, byte code definition, class
From debian I'd expect a policy that helps and guides java
apps/libs/jvm
maintainers to build and package their stuff with a focus on free
VMs, gives pointers who to get in topuch with if things don't work,
has a section on free java developers working on providing a free
java
I haven't used JNI much, so it would be nice if someone who packages a JNI
library could chip in here and provide some insight about what's necesary, and
how they use to find it.
For libreadline-java:
It builds explicitly against gcj and gcjh with the /usr/include/jni.h
provided by
2.2. Java Development Tools
[..]
Ant is used by some packages, but why mandate that ant must be used?
Is now changed to 'If package uses ant, then it must... \n If not, ...'
FWIW, this should use ant directive occurs in two places. Once in
section 2.7 (which you said earlier that you'd
Searching /lib and /usr/lib is what gcj does by default. Should this be
disabled to comply with the policy?
Policy only requires that /usr/lib/jni be added to the search path.
Whatever else you put there (e.g., /usr/lib, etc. for compatibility with
other distributions) is up to you.
Ben. :)
You mean something like
|You must depend on all working java virtual maschines and search all
|this packages for the java virtual maschine binary.
Yes.
I thought that this was fairly obvious... I mean, it's pretty stupit
if not :)
There are lots of things in debian policy that are
54 matches
Mail list logo
