[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Java packaging (was: [FW] Accepted kaffe 1:1.1.1-5.1 (i386 source))



Hallo Dalibor,

* Dalibor Topic wrote:
>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.

emacs? There are keybindings for emacs...

>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.

Sounds good. 

>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 will, as it becomes available in debian. :)

>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: I will try to package the eclipse 3.0 stream after the next
release (which should have been out since weeks, but I have just found
another bug in my packaging...). How far is kaffe with respect to this
version? There was just a big switch to OSGI-something bundles and lots
of other stuff. Would be great, if I could upload teh new packages to
main instead of contrib... Finaly autobuilders :)

[becomming DD]
>>I'm neither...
>You can become one! Go for it ;)

I'm in the NM process...

>Given my ever-growing list of duties with kaffe, classpath & mauve, I
>doubt I'd be a good debian developer myself.

:) 

[JPackage policy]

BTW: the scripts are here:
http://www.zarb.org/horde/chora/cvs.php/rpms/free/jpackage-utils?sa=1&rt=jpackage
They use shell scripts, as proposed here, but you can source them, so
startup files must be shell scripts.

The policy (plain xml...)
http://www.zarb.org/horde/chora/co.php/rpms/free/jpackage-utils/doc/Attic/jpackage-1.5-policy.xml?sa=1&rt=jpackage&r=1.1.2.5

[only support sun-derived JVM]
>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.

I thought so too. At least it made an attempt to share the config
rather pointless, as I couldn't agree with that position. See the
discussion at gmane.org (see below)

>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.

As long as you use only sun derived JVMs, it works great. The problem
is, that there only distinction beween JVM version is actually the
'API' version (or better: the version sun distributes to all the
license takers). They add all jars to the classpath of a JVM if this
jar wasn't already added (like JAXP in 1.4). So switching between JVM
versions is really just using a different java version.

This will break IMO in some cases (for example I think there isn't yet
a concept of /usr/lib/jni, so that native parts are added in all
cases) and of corse it will break when you don't have such a 'Version
A is better than version B' distinction, which you get when kaffe or
gij come into the game.

Have a look at 
http://article.gmane.org/gmane.linux.jpackage.general/3438 and
following (gmane.org has a very strange webinterface, use
http://news.gmane.org/gmane.linux.jpackage.general and scroll to the
second and third page (Nov 2003): "build-classpath and dependencies"
and [Fwd: "[JPackage-admin] JOnAS spec file + question" are the
threads)

>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?)

:) BTW: Jboss isn't packaged for debian, but JPackage already have it.
They are quite good when it comes to packaging! They also have lots of
JDK spec files (they do mostly the same as mpkg-j2sdk does), even for
such excotic ones like BEA (which I didn't know that it exist...).

>>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).

Gentoo has its java-config under
http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-java/java-config/

If I see that right, it also relies, that one JVM is set to a 'default
one', but they also have a 'java-config --classpath[=package1...]'
instead of the symlink system, which JPackage does.

>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.

I'm all for it. As long as the goal is to provide

* Dependecies, which work and ensure, that a package "will run"
* works with 'free replacements'
* lets the use have some choice which JVM to use

I'm all for it. Count me in, when you do such a proposal :)

Jan
-- 
Jan Schulz                     jasc@gmx.net
     "Wer nicht fragt, bleibt dumm."



Reply to: