JRE not recognised in eclipse IDE
by Yup Yup
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.
12 years, 10 months
Default java.library.path in Fedora
by Mat Booth
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
13 years, 1 month
get rid of maven *DEBUG*
by Christoph Höger
-----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-----
13 years, 1 month
SIG meeting (13:00 UTC, 16th of March)
by Stanislav Ochotnicky
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
13 years, 1 month
Eclipse ant support apparently missing
by Rob Scala
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
13 years, 1 month
Java Webapp installation
by Stanislav Ochotnicky
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
13 years, 1 month
eclipse cdt in F15
by Orion Poplawski
Has anyone tested the eclipse CDT in F15? It doesn't appear to load for me.
- Orion
13 years, 1 month
Unnecessary package dependencies on libgcj; broken "gcj_support" macro in SPEC file
by David Ward
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
13 years, 1 month
