Re: [FW] Accepted kaffe 1:1.1.1-5.1 (i386 source)
Hallo Dalibor,
* Dalibor Topic wrote:
>>Can someone certify, that this kaffe version is able to run eclipse
>>2.1.x?
>It runs it quite O.K. on my box, and rather fast. But you need to add
>the libswt-gtk.so directory to LD_LIBRARY_PATH.
That isn'T a problem, as I do that anyway in my startscript...
>The trouble is that you also need to do a bit of configuration, like
>setup Eclipse to use kaffe's rt.jar to build, etc, which may be a little
>hard for someone who's novice to both Java & Eclipse. I had problems
>getting Eclipse to use Kaffe as a Standard VM, maybe Mark Wielaard can
>help there, I've CC:ed him.
I will have a look at that (I think I remember a post on one of the
ML) and add that to the README or patch it in.
>Give it a try and judge for yourself. It's not 100% stable, though, the
>log file shows that some things still break. But there is definitely a
>large improvement since 1.1.2.
I haven't had a chance to do it and I think it won't happen before
Xmas. Personal question: Would you do development with eclipse on
kaffe? Without swearing every 5 minutes, because something breaks?
Thats aproximatly my barrier to add kaffe to the Depends: line and to
the findjava (internal function, not the proposed shell script) search
path.
>>BTW: is anyone still interested in this Proposal? Sometime ago I asked
>>Stephan to include it in java-common (the tools), but I got no
>>response. Should I package a seperate package and ask for a sponsor
>>for it, so that I can start to send some patches?
>I'm interested, as it would be an improvement over the current situation
>in my opinion. But I'm not a DD ;)
I'm neither...
>Btw, how did your conversation with JPackage guys end up? They seem to
>have some ideas in common with with debian-java, so I was wondering if a
>distribution independant Java application/library packaging effort would
>have a standing chance.
JPackage currently has the policy, that they add every jar to the
classpath and treat JDK1.3+JAXP=JDK1.4. They use virtual packages fo
this and something like the once proposed 'sun-derived-1.4' interface.
They don't have a possibility to use non sun-derived JDKs, until they
will be as mature as a sun-derived (mature as in 'add as many jars
until it is complete and it will work'). They also rely on a JAVA_HOME
like interface.
The main work (as in 'findjava' and 'java-config --getclasspath') will
be done at postinst level, where symlinks are used to setup the
environment. The thing is quite complicated and 'developer-friendly'
(the model case was ant and being able to adjust the classpath, so
that ant can be used with different implementations of some tasks) and
low level.
I asked them how they will manage kaffe and gij and the answer was:
They should get 'mature enough' and it will work out.
There is a policy in CVS, but quite hidden due to the ViewCVS version,
which will show up branches in the attic.
Funnily, I had also a look at gentoo, and they came up with some
scripts 'inbetween' the debian java proposal and Jpackage ones. The
whole issue would benefit from some standards, prefereable developed
and promoted from freedesktop.org (JPackage was interested in such a
project).
Jan
--
Jan Schulz jasc@gmx.net
"Wer nicht fragt, bleibt dumm."
Reply to: