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