CCing fedora-devel-java-list
* rivasdiazx-jpackage(a)yahoo.com <rivasdiazx-jpackage(a)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