[fedora-java] Re: [JPackage-discuss] Why libswt3-gtk2 isn't split between lib and plugin? also multiple SWTs and GCJ binaries

[Andrew Overholt]

CCing fedora-devel-java-list

* rivasdiazx-jpackage at yahoo.com <rivasdiazx-jpackage at yahoo.com> [2005-04-08 20:15]:
> 
> Problem+Proposal 1: 
> In both cases I found that the package libswt3-gtk2 installs SWT JARs
> and SOs as an independent library (in /usr/lib) and as an eclipse
> plugin (in /usr/share/eclipse/plugins). I think that this package
> should be splitted in lib and plugin. Something like libswt3-gtk2 and
> eclipse-swt3-gtk2 which depends on the former.

This doesn't work.  The libraries are needed for SWT since it has native
bits.

> Problem+Proposal 2:
> I think that libswt3 should be a generic package and should exist
> libswt3-gtk2, libswt3-motif, even maybe libswt3-fox, which are platform
> dependant. [...]

This would be fine, but we'd have to add back in the motif stuff and figure
out how to build the fox stuff.  It's not impossible, but it'd be a lot of
work.  This is why we have libswt3-gtk2, BTW.

> Problem+Proposal 3:
> FC4 will include Eclipse IDE and some plugins (very good!) but it will
> require the GCJ based java implementation, because they have compiled

Yes and no.  I recently added the requirement on java-1.4.2-gcj-compat
because we don't want people to think they're running our native packages
when they are actually running them on a proprietary JVM.  If someone has
their alternatives set up for, say, the Sun JVM, our packages will work
without the native bits (all the .jar.so files) entirely.

> more GCJ bugs reported, etc), but it will make a fork on JPackage RPMs
> and users will not be able to update to new versions using JPackage
> RPMs.

David Walluck and I have been talking about adding some sections to our
(FC) RPMs so that they are basically the same as the JPackage pure bytecode
ones.  I believe Tom Fitzsimmons has worked with the various depsolvers
(yum, up2date) to make sure that arch->noarch and noarch->arch upgrades
work fine.

> Something like eclipse-jdt (-base?) and eclipse-jdt-gcj.

No.  :)  Many discussions took place about this and that's not the
direction that we decided to take.  Tom, Fernando, Gary, and others can
explain more if necessary.

> process should invoke the Java Engine the standard way (JNI?,
> /usr/bin/java?), then if I have GCJ as my selected Java virtual
> machine, Eclipse will run with GCJ (as it will run in base FC4), but if

That's how we've set things up with java-gcj-compat.  If you have j-g-c set
up as your java alternative and you run Eclipse, it'll use the
natively-compiled stuff.  If you have another JVM set as your alternative,
it will seamlessly use it and ignore the native bits.

> PD: I made a fast search on the list to find something on this, I
> apologize if it was discused before.

That's cool.  Not much of this was discussed on list and I apologize for
that.  Thanks for the interest and suggestions!  Hopefully my comments
clear things up a bit.

Andrew