CCing fedora-devel-java-list * rivasdiazx-jpackage@xxxxxxxxx <rivasdiazx-jpackage@xxxxxxxxx> [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
