[Kde-java] standardized java-kde app packaging

[Richard Dale]

On Monday 08 March 2004 14:07, Adrian Petru Dimulescu wrote:
> Hello,
>
> as I already said, I'm experimenting with a Java-kde application (a
> development of George Russell's gilt).
>
> I wonder what to do as far as packaging is concerned: normally, a
> non-basic KDE application, comes with a ./configure, requires kdelibs
> and parhaps kdebase; what should require a kde-java app? I guess all
> that and kdebindings for java. But as the libraries are in jar form and
> not already natively compiled, should my application package do the
> compiling of koala.jar and qtjava.jar ?
>
> Or should I simply wait for a kde-java version which compiles itself by
> default ?
I'll try and find out what the problem is in the 'admin/ltmain.sh' script that 
generates the faulty 'libtool' script, I will ask on the kde-core-development 
list. It might be possible to work round it by not using automake commands in 
the Makefile.am, just have normal make ones which invoke gcj directly rather 
than via the libtool script.

> Is there an example automake/conf I could follow? I haven't been able to
> get the sample Java skeleton app in KDevelop to compile, so I 'm pretty
> confused at this point.
I'm afraid I haven't looked at KDevelop for a while, I've been too busy just 
doing language bindings. The example in kdejava/koala/test/kbase should be 
the same as the KDevelop template - I did make some small changes to that to 
get it to work with KDE 3.2.

> All that because I think that doing a KDE Java application which
> requires the JVM is simply not something users would accept. I wouldn't
> take the pain myself of installing a  JVM and run an unintegrated,
> KDE-unaware Java application -- if I had the choice, of course. So I
> think JavaKDE could only work in the natively compiled  form.
Yes a Sun jdk is a pain to install, and often doesn't work with your 
distribution because as it's binary only, it may be compiled with a different 
incompatible version of gcc. Many platforms aren't well supported - I use a 
PowerPC version of Linux and the latest jdk is only 1.3.1 for that. 

gcj is much more suitable for KDE/Free Software - either compiled or 
interpreted via gij, and I don't think for most apps the speed difference is 
noticeable. I would just start up the gij interpreter with a script in the 
KDE bin directory - it would need to be able to find the directory containing 
the gilt.jar file of the app via the KDE KStdDirs/KInstance mechanism.

-- Richard