java-devel March 2011

java-devel@lists.fedoraproject.org

13 participants
10 discussions

JRE not recognised in eclipse IDE
by Yup Yup 14 Jun '11

14 Jun '11

Hi, I installed eclipse-platform-3.5.2-2.fc13.x86_64 on Fedora 13. Java has been installed on the system. ca1@localhost ~]$ java -version java version "1.6.0_18" ...... But, Java runtime is not recognised in the Eclipse IDE. Under Menu....... Window>Preferences there are no installed JREs options. Also, no Java project, class options in the menu is available.

5 5

Eclipse EMF build failures
by Mat Booth 30 Mar '11

30 Mar '11

Hi all, I'm trying to update EMF to 2.6.1, but it's failing to build source bundles. Looking at Koji[1], it looks like it stopped building after Eclipse was updated from 3.6.0 to 3.6.1. (The same version that built with Eclipse 3.6.0 failed the F15 mass rebuild, which was with Eclipse 3.6.1) The build log [2] claims not to be able to find the source feature, but this doesn't make sense to me because other plug-ins like GEF also do not explicitly have source bundles but rather they are generated from templates, so I cannot see why GEF builds where EMF does not. Can anyone help me? Mat [1] http://koji.fedoraproject.org/koji/packageinfo?packageID=1641 [2] http://koji.fedoraproject.org/koji/taskinfo?taskID=2929605 -- Mat Booth http://fedoraproject.org/get-fedora

2 1

Default java.library.path in Fedora
by Mat Booth 28 Mar '11

28 Mar '11

In F14's OpenJDK, the default java.library.path currently does not include /usr/local/lib or /usr/local/lib64 so if a third party JNI library installs itself into one of those directories then the JVM will not know about it. Is this a bug? I think it would be appropriate if /usr/local/lib and /usr/local/lib64 were included in the default java.library.path Thanks, Mat -- Mat Booth http://fedoraproject.org/get-fedora

5 8

get rid of maven *DEBUG*
by Christoph Höger 17 Mar '11

17 Mar '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, does anyone know why fedoras maven spills out *DEBUG* messages by default and how to get rid of them? thanks, Christoph - -- Christoph Höger Technische Universität Berlin Fakultät IV - Elektrotechnik und Informatik Übersetzerbau und Programmiersprachen Sekr. TEL12-2, Ernst-Reuter-Platz 7, 10587 Berlin Tel.: +49 (30) 314-24890 E-Mail: christoph.hoeger(a)tu-berlin.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk2B4m4ACgkQhMBO4cVSGS9FvQCdHILMyjkB3a2GcaaFNU/kO0yx N14An0SiyGpp0/t+yt34ySFKT//GwjRT =rv61 -----END PGP SIGNATURE-----

3 2

SIG meeting (13:00 UTC, 16th of March)
by Stanislav Ochotnicky 16 Mar '11

16 Mar '11

For Meeting page see [1]. Basically the main topic are forthcoming changes in packaging guidelines, mainly use of Maven 3 instead of Maven 2 and wider use of some jpackage-utils scripts that have been under-utilized[2]. I would like to add use of "clean-binary-files" but I have yet to figure out how exactly it's supposed to work :-) Help there would be appreciated. It would be great to fit these changes with JNI changes that should be coming shortly[3]. Although I am starting to think that there are quite a few problems that need to be solved for multilib-aware JNI packages and it might be better to go ahead even without JNI changes. Also one of the things we need to discuss. [1] https://fedoraproject.org/wiki/Meeting:Java_SIG_2011-03-16 [2] http://bit.ly/dLJLv4 [3] https://bugzilla.redhat.com/show_bug.cgi?id=665576 -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

1 1

F15 Eclipse SVN commit dialog
by Jim Hayward 16 Mar '11

16 Mar '11

Hi All, I'm seeing a problem with the SVN commit dialog in F15. The dialog only displays the text asking you to enter a comment and the cancel/ok buttons. There isn't anywhere to enter the comment. You cannot resize the dialog to try and expose the missing widgets. Is anyone else seeing this problem. screenshot... http://www.linuxexperience.net/screens/svn_commit_dialog.png Regards, Jim H

2 5

Eclipse ant support apparently missing
by Rob Scala 15 Mar '11

15 Mar '11

I recently installed eclipse on my f14 box, and I can't get ant support to work. No ant preferences. No ant editor. Am I missing some package? Here is what I have installed: eclipse-platform-3.6.1-6.1.fc14.x86_64 eclipse-jdt-3.6.1-6.1.fc14.x86_64 eclipse-subclipse-1.6.16-1.fc14.noarch tomcat5-jasper-eclipse-5.5.27-7.4.fc12.noarch eclipse-swt-3.6.1-6.1.fc14.x86_64 eclipse-rcp-3.6.1-6.1.fc14.x86_64 icu4j-eclipse-4.2.1-1.fc14.x86_64 eclipse-gef-3.6.1-1.fc14.noarch eclipse-svnkit-1.3.3-5.fc14.noarch Thanks for your help, Rob

3 7

Java Webapp installation
by Stanislav Ochotnicky 09 Mar '11

09 Mar '11

I've been asked to package apache-solr [1] in Fedora. This is a java library and webapp posing as a frontend to lucene for searching. Packaging java jars is not a problem, but there are more problems with webapp part. I made it into subpackage apache-solr-webapp. Ant build creates war file (basically a zip with metadata and dependencies bundled). I expand this war file and replace dependencies with symlinks to %{_javadir}. I then place content of this directory inside /usr/share/java/webapps/apache-solr/. This makes it possible to use webapp in container (tomcat/jetty) while enabling us to update dependencies independently. I was thinking about adding default configuration for tomcat inside yet another subpackage. But this would be just one simple xml file inside /etc/tomcat6/Catalina/localhost/. Plus solr needs additional configuration: * creating of SOLR_HOME directory and placing it somewhere, presumably /var/lib/solr). I have example solr home dir in %doc, but it is generic and configuration is not really usable in that state for anything other than serve as a commented example. All in all seems like too much of a hassle for little gain. Someone who is installing webapp should probably be able to deploy it (it's point and click with manager webapp, or one simple 3-line long xml). Plus I'd have to add another subpackage for jetty I guess... My approach is similar to what we discussed on Java SIG meeting in December and what was proposed in debian packaging draft[2]. We don't have a tool to make deployments of webapps from /usr/share/java/webapps into proper container directories yet, so this burden will stay with users (for now). I'd like to get more input on my approach and see if anyone sees a problem with this. Note that there is no guideline for Java webapps as of now so keep it light :-) [1] http://wiki.apache.org/solr/ [2] http://dep.debian.net/deps/dep7/ -- Stanislav Ochotnicky <sochotnicky(a)redhat.com> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com

2 1

eclipse cdt in F15
by Orion Poplawski 08 Mar '11

08 Mar '11

Has anyone tested the eclipse CDT in F15? It doesn't appear to load for me. - Orion

2 2

Unnecessary package dependencies on libgcj; broken "gcj_support" macro in SPEC file
by David Ward 07 Mar '11

07 Mar '11

I know that people have asked in the past about removing gcj from Fedora in favor of OpenJDK, and I'm aware that this has not happened for reasons including architecture support on some platforms. I don't know when this was assessed last, but I'm leaving that question alone for now. The Java packages I have examined in Fedora 14 are forcibly built using gcj so that the AOT bits are included, which is fine. However, during the final stages of packaging, rpmbuild searches and finds the AOT bits, sees that they link against libgcj_bc.so.1, and automatically adds that as a dependency to the package. The packages should not, however, depend on libgcj -- they can be used as-is with OpenJDK or another JRE, simply ignoring the AOT bits. This is analogous to not requiring 'man-db' to be installed if a package contains man files, or not requiring 'gdb' to be installed if a package contains debug symbols. You can take advantage of those if you would like, but they are not required for use. So can we fix the rpmbuild macros so that the AOT bits are ignored when automatically adding dependencies? Also on this topic, there is a macro in the SPEC file of a lot of the Java-based packages that doesn't work quite right: %define gcj_support %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support:%{_gcj_support}}%{!?_gcj_support:0}}} Somehow this always defines "gcj_support" as 1, even if I do "rpmbuild --without gcj_support". If I slightly alter the way the macro is written, then it seems to have the intended effect: %define gcj_support %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support}%{!?_gcj_support:0}}} Some packages additionally hard code this value, using one of these two lines: %define _with_gcj_support 1 %define gcj_support 1 Those lines needs to be removed wherever they appear. Fedora 14's rpmbuild macros set "_gcj_support" to 1, so this is the default if no options are given and the long macro above is included. A user ought to still be able to do "rpmbuild --without gcj_support" if they want, without having to edit the SPEC file. Thanks, David

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

java-devel March 2011