java-devel July 2008

java-devel@lists.fedoraproject.org

21 participants
9 discussions

blueMarine and openJDK -- second attempt
by Matej Cepl 24 Aug '08

24 Aug '08

Hi, I was trying once already to use blueMarine image cataloging program with IcedTea (which was then still too raw; http://thread.gmane.org/gmane.linux.redhat.fedora.java/2311). Now when the OpenJDK was officially certified to be a Java, I tried again, and I wasn't that much successfull either. Could anyboyd who actually understands Java and Fedora, could join a thread on http://bluemarine.tidalwave.it/forum/posts/list/1179.page and something useful there, please? Thanks a lot, Matěj

6 24

Eclipse 3.4
by Andrew Overholt 07 Aug '08

07 Aug '08

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.

6 14

NetBeans 6.1
by Alexei Mokeev 31 Jul '08

31 Jul '08

Hi, I'd like to consult with you about reviewing packages for Netbeans (http://www.netbeans.org) ?. The packages are ready and review requests are in BugZilla. (https://bugzilla.redhat.com/showdependencytree.cgi?id=456337). According to rpmlint they are not in a bad shape :) since it shows no errors. These packages are also in 'active' support, so if it's necessary to change something we are ready to do so quickly. Thanks, -Alexei.

1 0

jna and gstreamer-java on fedora
by Farkas Levente 30 Jul '08

30 Jul '08

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!"

6 9

jakarta-commons-cli
by Anthony Green 14 Jul '08

14 Jul '08

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

1 0

jna rpm
by Farkas Levente 11 Jul '08

11 Jul '08

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!"

1 1

gcj bits fail to build for Eclipse [Matt_Domsch@dell.com: Fedora i386 rawhide rebuild in mock status 2008-07-03]
by Andrew Overholt 09 Jul '08

09 Jul '08

Specific build log: http://linux.dell.com/files/fedora/FixBuildRequires/mock-results-core/i386/… Reproducer: cvs -d:pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs co eclipse cd eclipse/devel make <i386|x86_64> Andrew

2 3

packaging lessons from FUDCon hackfest?
by Karsten Wade 07 Jul '08

07 Jul '08

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

5 7

libvirt-java bindings
by Daniel Veillard 03 Jul '08

03 Jul '08

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/

8 32

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel July 2008