Eclipse 3.4
by Andrew Overholt
Hi,
I've finally got version 3.4 of the Eclipse SDK ready to go, targetting
Fedora 10:
http://koji.fedoraproject.org/koji/buildinfo?buildID=58121
(See [1] for an in-progress build with some minor fixes.)
Action item for plugin package maintainers:
-------------------------------------------
Please look at the relevant attached patches and apply them or something
like them in the devel directory of your plugin(s). Feel free to commit
and tag but note that you won't be able to build until I tag the build
for rawhide.
Email me personally if you have questions. Please also let me know when
you're finished and I can do koji builds of everything in the right
order (chain-build or otherwise). I'd like to do this very soon so
please take a few minutes to apply the changes.
Testing of the above build is greatly appreciated.
-------------------------------------------
There are a few minor changes for packagers of plugins/features:
- Bits are now installed to %{_libdir}/eclipse instead of
%{_datadir}/eclipse. This brings us in line with upstream's file layout
and avoids the crazy split-install osgi.sharedConfiguration.area hack.
It's also what Debian does, FWIW.
- p2 is the new provisioning platform in 3.4. Essentially it replaces the
old update manager but does other things as well. It requires
Eclipse-based apps to use profiles -- like Mozilla profiles -- and manage
them using its "director". In order to avoid fragile %post scriptlets,
we're going to use the "dropins mechanism" for plugin installation. This
means that all non-Eclipse platform plugins will be installed into their
own directory under %{_libdir}/eclipse/dropins. There are a variety of
layouts that are acceptable to p2, but we'll largely be going with
dropins/eclipse/<short name>/{plugins,features}. This has the nice side
benefit of simplifying %files sections :) . See [2] for more
information here.
- I added a flag to the pdebuild script to allow for Orbit-style
dependencies. If you don't know what this means, that's okay, but if
a plugin you want to package uses Orbit dependencies, you'll want to
use the -o flag to pdebuild. Plugins that use non-Eclipse JARs but
don't have a lib directory with JARs are probably using Orbit-style
dependencies. They'll have Require-Bundle or Import-Package entries
in their plugin MANIFEST.MFs. See eclipse-mylyn for an example of how
to use pdebuild in this case.
- I've renamed (and Obsoleted/Provided) libswt3-gtk2 to eclipse-swt. I
can't count the number of times people have been confused by this
naming and since we're not going to ship swt2 or swt.motif any time
soon, the naming is silly. I also folded pde-runtime into pde since
PHPEclipse no longer needs the separate pde-runtime package.
Outside of the CDT and the SELinux tools (both maintainers are working on
the necessary changes themselves), I've got patches for all of the plugins
we have as packages in Fedora. I've attached these patches and CC'd all of
the maintainers.
I will update the packaging guidelines very soon with the above
information.
Thanks,
Andrew
[1]
Build with branding fixed and removing some unnecessary Requires(post)
and the pde-runtime package which is now folded into pde:
http://koji.fedoraproject.org/koji/taskinfo?taskID=750696
[2]
There are some performance considerations here. Since it's generating
the associated metadata and "provisioning" the bits on the fly based on
files dropped into a directory, users may notice a slightly longer
startup the first time they start the Eclipse IDE after installing a new
plugin package. Subsequent startups won't be impacted. There is a lot
of performance improvement work going on upstream and much of it will
land in 3.4.1. If 3.4.1 is released early enough, we'll ship it in
Fedora 10. If not, we can ship it as an update. Should testing between
now and Fedora 10 show unacceptably poor performance (I haven't noticed
this in my own testing), we can look at back-porting some of the
performance work. The other main way of speeding up dropins-installed
plugins is by shipping pre-generated p2 metadata (like yum metadata).
I've experimented with this and think I can make it so that we
transparently generate it via pdebuild meaning it would only require a
rebuild of Fedora plugin packages. Things will work without these
generated content.xml files so in the interest of getting testing sooner
rather than later, I'm going to push ahead without the metadata for
dropins.
15 years, 1 month
jna and gstreamer-java on fedora
by Farkas Levente
hi,
unfortunately it seems we don't really test the rpm package:-(
the main problem is the jna. it seems the jna package provided by fedora
is not working with our rpm and even with gstreamer-java compiled from
source. we always got such problems (like in test):
---------------------------------------------
[junit] Testsuite: org.gstreamer.BinTest
[junit] #
[junit] # An unexpected error has been detected by Java Runtime
Environment:
[junit] #
[junit] # SIGSEGV (0xb) at pc=0xb24b000b, pid=12123, tid=1616784
[junit] #
[junit] # Java VM: OpenJDK Server VM (1.6.0-b09 mixed mode linux-x86)
[junit] # Problematic frame:
[junit] # C 0xb24b000b
[junit] #
[junit] # An error report file with more information is saved as:
[junit] # /tmp/gstreamer-java/hs_err_pid12123.log
[junit] #
[junit] # If you would like to submit a bug report, please visit:
[junit] # http://icedtea.classpath.org/bugzilla
[junit] # The crash happened outside the Java Virtual Machine in
native code.
[junit] # See problematic frame for where to report the bug.
[junit] #
[junit] Test org.gstreamer.BinTest FAILED (crashed)
---------------------------------------------
what can be the reason? the jna.jar packaged with gstreamer-java is
working properly, but not the jna in fedora.
does anybody use the jna package in fedora? is it working? can we've do
something? or should i've to package the jna provided by gstreamer-java
or reuild the original jna and not use the fedora one?
thanks in advance.
yours.
--
Levente "Si vis pacem para bellum!"
15 years, 1 month
jakarta-commons-cli
by Anthony Green
I'd like to surrender maintainership of jakarta-commons-cli to somebody
more directly invovled in the jpackage effort (or somebody interested in
getting involved).
The first task at hand is to upgrade to 1.1.
Any takers?
AG
15 years, 2 months
jna rpm
by Farkas Levente
hi,
i heard that someone already made a jna rpm for fedora. can anybody
point me to any sources? anyway i like to add jna a gstreamer-java
packages to fedora which we made if anybody has these packages already
made then we merge the spec file together.
yours.
--
Levente "Si vis pacem para bellum!"
15 years, 2 months
packaging lessons from FUDCon hackfest?
by Karsten Wade
Andrew Overholt and Tom Fitzsimmons sat with a guy from Alfresco (Lee
Faus) last Friday in the FUDCon hackfests. Mainly they were doing a
code review with him to see what he has to do to get Alfresco packaged
for Fedora. It was a great effort, and possibly enlightening for
everyone as to the scope of the problem ahead of us to get Java ISVs
packaged in Fedora.
Andrew, Tom -- where there any insights, lessons, ideas, or other
outfalls from that work with Lee?
Two specific areas of interest are:
* Tips, ideas, or plans for Java packaging ==> target
wiki/Packaging/Java
* ISV-specific lessons, tips, etc. ==> target wiki/SIGs/ISV
I'm asking on this list because I think a brain dump from both of you
here would give good exposure. I'm ready to glean content to make the
above wiki updates. :)
- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
15 years, 2 months
libvirt-java bindings
by Daniel Veillard
Hi,
I have just started to release and package java bindings for libvirt.
I have made a request for review for Fedora on the new package:
https://bugzilla.redhat.com/show_bug.cgi?id=453119
I found the exercise rather hard, JNI is of course on the edge of the Java
land, but it's hard to find good resources to look at for Java bindings
in Fedora, the gnome-java stuff seems very specific, and a lot of packages
basically rely on gcj for compilation of any JNI stuff.
I would like something more flexible, to that end I added some JDK dynamic
detection in configure.in for my package, which then allows to guess the
jni.h and jni_md.h based on the javah and javac used to generate the bindings
(so things should stay consistent).
In the spec file I used the following:
%define java java
and
Requires: %{java} >= 1.5.0
BuildRequires: %{java}-devel >= 1.5.0
to easilly allow the user to specify more strictly what java development
package to use. I don't know if this is sufficient in general for the
previous versions of Fedora, it seems to work with java-1.6.0-openjdk
in F-9 or something as old as java-1.5.0-ibm-1.5.0.7 on a RHEL-4 box,
but the java class compilations break for example with java-1.5.0-gcj [-devel]
on Fedora-8 (didn't tried icedtea yet, though I guess that would work)
this looks related to dependancies when compiling a bunch of .java
together in one command as
/usr/bin/javac -classpath "org/libvirt" org/libvirt/*.java
2. ERROR in org/libvirt/VirConnectAuthDefault.java (at line 14)
credType= new VirConnectCredential.VirConnectCredentialType[] {
^^^^^^^^
credType cannot be resolved
though VirConnectCredential.java is there and defines the type.
Portability tricks and eyeballs for the review would be very welcome !
(as well as patches to improve the package source of course but that
would be best conducted on the libvirt list).
thanks in advance,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
15 years, 2 months
