Re: [FW] Accepted kaffe 1:1.1.1-5.1 (i386 source)
Hallo Jan,
Jan Schulz wrote:
Hallo Dalibor,
* Dalibor Topic wrote:
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?
I've tried to do developement in eclipse today, and I was swearing every
5 minutes,because I found the interface to be so weird. I had a very
hard ti efiguring out what button to press where to get a CVS tree
imported etc. But kaffe coped with most of my amatuerish attempts to get
something done o.k.
Since I've never used eclipse for real before, I can't really say. So
I'd say wait for 1.1.4 or try it for yourself. I'll try to make the
switch to eclipse on kaffe (eating my own dogfood ;) and hope to have a
better answer in a month, or two.
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...
You can become one! Go for it ;)
Given my ever-growing list of duties with kaffe, classpath & mauve, I
doubt I'd be a good debian developer myself.
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.
Uh, that's bad news all the way. No need to rehash why the approach is
not that great, we've done it to death in our debian-java policy threads.
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.
Hm, I'd prefer a simple, user-friendly environment. But I haven't really
looked a JPackage internals myself, nor have I ever used JPackage, so I
can't say how user-friendly their setup is wrt our goals.
I asked them how they will manage kaffe and gij and the answer was:
They should get 'mature enough' and it will work out.
Is http://www.kaffe.org/~robilad/jboss-3.2.2-screenshot.png mature
enough? ;) (No, it doesn't run perfectly out of the box yet, but we're
getting there. Debian-enterprise devs, are you listening?)
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).
Funny that you mention freedesktop.org. We had a discussion or two on
IRC and on the Classpath mailing list the other day about doing
something wrt the freedesktop project, and aproaching them in the
context of free java runtimes. It seems like this would be the perfect
opportunity & theme for that with a good chances of mutual benefit for
all parties involved, free VMs, java application developers, as well as
java packagers.
cheers,
dalibor topic
Reply to: