Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
> >> kaffe, but sablevm installs a higher priority, then I'm fd up.
> >I think we both agree that this scheme is not a good
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
> >> kaffe, but sablevm installs a higher priority, then I'm fd up.
> >I think we both agree that this scheme is not a good
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
> >I beg to disagree. I want to be able to change my preferences at runtime,
> >instead of having to rely on a packager to get it right when he packages the
> >application.
>
> Somewhere else you said, that it is ok for you if the packagers only
> uses one dependency (which implys, that only one
Hallo Dalibor,
* Dalibor Topic wrote:
>> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
>> kaffe, but sablevm installs a higher priority, then I'm fd up.
>I think we both agree that this scheme is not a good solution for java
>on debian. It doesn't give users the necessary
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
Hallo Dalibor,
* Dalibor Topic wrote:
>> '/usr/bin/java'. If sablevm and kaffe are installed and I depend on
>> kaffe, but sablevm installs a higher priority, then I'm fd up.
>I think we both agree that this scheme is not a good solution for java
>on debian. It doesn't give users the necessary
Hallo Dalibor,
* Dalibor Topic wrote:
>> This is not the primary goal of the policy IMO. The policy is for
>> describing *how* a package should look like, a kind of ruleset, which
>> packages have to comply to. Nothing more, nothing less.
>Well, the current proposal for a debian java policy contai
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >The definition of what's to be expected as normal keeps changing all the
> time
> >in the java world, as I'm trying to make clear with my questions on your
> >interpretation of java's class loading semantics.
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >The definition of what's to be expected as normal keeps changing all the
> time
> >in the java world, as I'm trying to make clear with my questions on your
> >interpretation of java's class loading semantics.
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> I much for this, but it will need 'protection', so that this system
> >> prevents to mistake kaffe for a sun compatible JVM-1.4.
> >Could you elaborate on this one, as in give an example where ka
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Dalibor,
>
> * Dalibor Topic wrote:
> >> I much for this, but it will need 'protection', so that this system
> >> prevents to mistake kaffe for a sun compatible JVM-1.4.
> >Could you elaborate on this one, as in give an example where ka
Hallo Dalibor,
* Dalibor Topic wrote:
>The definition of what's to be expected as normal keeps changing all the time
>in the java world, as I'm trying to make clear with my questions on your
>interpretation of java's class loading semantics.
>From your point, but not from the guy starting a java
Hallo Ben,
* Ben Burton wrote:
>FWIW (DFSG, point 4):
> "We will be guided by the needs of our users and the free-software
> community. We will place their interests first in our priorities."
>I would therefore very much expect Java policy to be designed with free
>JVMs as the focus, not as an
Hallo Dalibor,
* Dalibor Topic wrote:
>The definition of what's to be expected as normal keeps changing all the time
>in the java world, as I'm trying to make clear with my questions on your
>interpretation of java's class loading semantics.
>From your point, but not from the guy starting a java
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 n
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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?
Much better, actually, although I still have some issues with it. But I
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
Hi Ben,
--- Ben Burton <[EMAIL PROTECTED]> 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.
>
> For libreadline-java:
>
> It builds explicitly
Hallo Ben,
* Ben Burton wrote:
>FWIW (DFSG, point 4):
> "We will be guided by the needs of our users and the free-software
> community. We will place their interests first in our priorities."
>I would therefore very much expect Java policy to be designed with free
>JVMs as the focus, not as an
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 n
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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?
Much better, actually, although I still have some issues with it. But I
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
Hi Ben,
--- Ben Burton <[EMAIL PROTECTED]> 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.
>
> For libreadline-java:
>
> It builds explicitly
> 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 libgcj4
> >>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 libgcj4
> >>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
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 an
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
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
>
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:
>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 experie
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ean,
>
> * Ean Schuessler wrote:
> >The problem is that "java2-runtime-" 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 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 an
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
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
>
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 PROTECT
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 experie
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 garan
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. ;)
>
> Bu
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
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 ...
>
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Ean,
>
> * Ean Schuessler wrote:
> >The problem is that "java2-runtime-" 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 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 garan
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. ;)
>
> Bu
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
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 ...
>
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 enoug
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 op
Hallo Ben,
* Ben Burton wrote:
>> >Then why push for $JAVA_HOME, which suffers from the same problem?
>> Because I think there are a lot of programs, which rely on the
>> 'java.home' property to be set. Here is for example the result on
>> going thru the ant tasks. ant is IMO one of the important
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 enoug
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 op
Hallo Ben,
* Ben Burton wrote:
>> >Then why push for $JAVA_HOME, which suffers from the same problem?
>> Because I think there are a lot of programs, which rely on the
>> 'java.home' property to be set. Here is for example the result on
>> going thru the ant tasks. ant is IMO one of the important
> >Then why push for $JAVA_HOME, which suffers from the same problem?
>
> Because I think there are a lot of programs, which rely on the
> 'java.home' property to be set. Here is for example the result on
> going thru the ant tasks. ant is IMO one of the important packages,
> which should be made
> >Then why push for $JAVA_HOME, which suffers from the same problem?
>
> Because I think there are a lot of programs, which rely on the
> 'java.home' property to be set. Here is for example the result on
> going thru the ant tasks. ant is IMO one of the important packages,
> which should be made
Hallo Ben,
* Ben Burton wrote:
>I'm really not sure what you mean here. At the moment, using $CLASSPATH
>is somewhat *more* portable across different JVMs than using -classpath.
>In particular, it doesn't suffer from the ever-changing command-line
>syntax, nor does it override the bootstrap class
Hallo Ben,
* Ben Burton wrote:
>I'm really not sure what you mean here. At the moment, using $CLASSPATH
>is somewhat *more* portable across different JVMs than using -classpath.
>In particular, it doesn't suffer from the ever-changing command-line
>syntax, nor does it override the bootstrap class
> >Can we use $CLASSPATH instead of -classpath? From my experience making
> >packages work with both free and proprietary JVMs, setting $CLASSPATH
> >before calling the java runtime (instead of passing -classpath, -cp,
> >whatever) has caused the least breakage.
>
> With some clear idea about *w
Hallo Dalibor,
* Dalibor Topic wrote:
>> Kaffe is actually mostly compatible with the JAVA_HOME "standard" now
>> that I use symlinks for Debian compatibility. It might be worth making
>> the JAVA_HOME structure part of Debian policy. GCJ and friends could
>> create some simulation of it by symlin
Hallo Dalibor,
* Dalibor Topic wrote:
>I sense a contradiction here. Either the interface is meant for non-compliant
>free VMs as well, then the first paragraph is weird, or the free VMs will be
>handled separately, but then there is no interface, so the second paragraph is,
>huh, weird ;)
Aem, y
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 fixed. There is no reason to use JAVA_HOME.
I think we just
Hallo Dalibor,
* Dalibor Topic wrote:
>> it is names) and it should be fine. If thats the search path for
>> classes... Without, we probably can't use kjc, as a javac replacement
>> or ant compiler, as the result would be unpredictable, especially when
>> a programm wants to have a newer version o
Hallo Dalibor,
* Dalibor Topic wrote:
>> -classpath :, where is a full path to a
>> Java Archiv file.
>So you've just forbid the use of directories in -classpath per policy.
>Are you sure you want to do that? ;)
In packages: yes. Policy requires, that all puiblic jar files are in
/usr/share/jav
Hallo Ben,
* Ben Burton wrote:
>Can we use $CLASSPATH instead of -classpath? From my experience making
>packages work with both free and proprietary JVMs, setting $CLASSPATH
>before calling the java runtime (instead of passing -classpath, -cp,
>whatever) has caused the least breakage.
With some
> >Can we use $CLASSPATH instead of -classpath? From my experience making
> >packages work with both free and proprietary JVMs, setting $CLASSPATH
> >before calling the java runtime (instead of passing -classpath, -cp,
> >whatever) has caused the least breakage.
>
> With some clear idea about *w
Hallo Dalibor,
* Dalibor Topic wrote:
>> Kaffe is actually mostly compatible with the JAVA_HOME "standard" now
>> that I use symlinks for Debian compatibility. It might be worth making
>> the JAVA_HOME structure part of Debian policy. GCJ and friends could
>> create some simulation of it by symlin
Hallo Dalibor,
* Dalibor Topic wrote:
>I sense a contradiction here. Either the interface is meant for non-compliant
>free VMs as well, then the first paragraph is weird, or the free VMs will be
>handled separately, but then there is no interface, so the second paragraph is,
>huh, weird ;)
Aem, y
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 fixed. There is no reason to use JAVA_HOME.
I think we just
Hallo Dalibor,
* Dalibor Topic wrote:
>> it is names) and it should be fine. If thats the search path for
>> classes... Without, we probably can't use kjc, as a javac replacement
>> or ant compiler, as the result would be unpredictable, especially when
>> a programm wants to have a newer version o
Hallo Dalibor,
* Dalibor Topic wrote:
>> -classpath :, where is a full path to a
>> Java Archiv file.
>So you've just forbid the use of directories in -classpath per policy.
>Are you sure you want to do that? ;)
In packages: yes. Policy requires, that all puiblic jar files are in
/usr/share/jav
Hallo Ben,
* Ben Burton wrote:
>Can we use $CLASSPATH instead of -classpath? From my experience making
>packages work with both free and proprietary JVMs, setting $CLASSPATH
>before calling the java runtime (instead of passing -classpath, -cp,
>whatever) has caused the least breakage.
With some
> > This is somewhat more difficult to arrange with command-line options.
>
> java -classpath foo.jar:bar.jar:$CLASSPATH
Heh. :)
*slap*
> > This is somewhat more difficult to arrange with command-line options.
>
> java -classpath foo.jar:bar.jar:$CLASSPATH
Heh. :)
*slap*
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hallo Ean,
* Ean Schuessler wrote:
>On Tue, 2003-09-02 at 16:10, Jan Schulz wrote:
>The difference is that the Kaffe package would not try to provide
>"j2sdk1.4". Kaffe just provides "kaffe". Packages that know they will
>work with Kaffe can explicitly depend on it.
Sorry, if I haven't made that
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
>> question.
>The ugly point is that almost every VM
On Wed, Sep 03, 2003 at 09:29:23AM +1000, Ben Burton wrote:
> In addition, if a user wants to add their own classes to the classpath
> (e.g., with jython where adding your own classes can be advantageous
> even if the app itself doesn't need them), they can set $CLASSPATH
> before running the scri
Hallo Ean,
* Ean Schuessler wrote:
>On Tue, 2003-09-02 at 16:10, Jan Schulz wrote:
>The difference is that the Kaffe package would not try to provide
>"j2sdk1.4". Kaffe just provides "kaffe". Packages that know they will
>work with Kaffe can explicitly depend on it.
Sorry, if I haven't made that
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
>> question.
>The ugly point is that almost every VM
On Wed, Sep 03, 2003 at 09:29:23AM +1000, Ben Burton wrote:
> In addition, if a user wants to add their own classes to the classpath
> (e.g., with jython where adding your own classes can be advantageous
> even if the app itself doesn't need them), they can set $CLASSPATH
> before running the scri
Hi Ean,
--- Ean Schuessler <[EMAIL PROTECTED]> wrote:
> Something I have just now thought of that might make more sense. What if
> we use Classpath as the standard instead of the Sun VM releases?
>
> Therefore,
> Kaffe: provides: Classpath-0.5
> ORP: provides: Classpath-0.5
> J2SDK1.4: provides:
Hi Ean,
--- Ean Schuessler <[EMAIL PROTECTED]> wrote:
> Something I have just now thought of that might make more sense. What if
> we use Classpath as the standard instead of the Sun VM releases?
>
> Therefore,
> Kaffe: provides: Classpath-0.5
> ORP: provides: Classpath-0.5
> J2SDK1.4: provides:
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> And the thing is, it will work. JAVA_HOME is not advertised anywhere,
> but almost every startscript uses it. man ant, man eclipse, man
> tomcat4 (oups: "No manual entry for tomcat4", which tomcat4:
> /usr/bin/tomcat4). All use it, but no wor
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Matt,
>
[snip]
> This interface is not for the free ones but only for the sun complient
> ones (Sun, BD, IBM). The rest will be handled independently.
[snip]
> With this interfaces you can install a package and know that it will
> run, even if
--- Ean Schuessler <[EMAIL PROTECTED]> 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 fa
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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 classpa
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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 su
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> And the thing is, it will work. JAVA_HOME is not advertised anywhere,
> but almost every startscript uses it. man ant, man eclipse, man
> tomcat4 (oups: "No manual entry for tomcat4", which tomcat4:
> /usr/bin/tomcat4). All use it, but no wor
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> Hallo Matt,
>
[snip]
> This interface is not for the free ones but only for the sun complient
> ones (Sun, BD, IBM). The rest will be handled independently.
[snip]
> With this interfaces you can install a package and know that it will
> run, even if
--- Ean Schuessler <[EMAIL PROTECTED]> 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 fa
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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 classpa
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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 su
Hallo Jan,
--- Jan Schulz <[EMAIL PROTECTED]> wrote:
> 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
> 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
1 - 100 of 248 matches
Mail list logo
